Money transfer using canonical url

ABSTRACT

In one embodiment, a method includes receiving, a registration request from a first user including information relating to an account of the first user and a unique payment proxy to be associated with the first user. The method includes storing the unique payment proxy in association with the account of the first user. The method includes receiving, from a mobile device of a second user, a request to transfer funds to the first user. The method includes identifying the account of the first user by retrieving the information relating to the account of the first user from the database using the unique payment proxy included in the request. The method includes providing instructions to display a user interface on the mobile device of the second user to facilitate the transfer. The user interface is personalized for the first user.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation under 35 U.S.C. § 120 of U.S. patentapplication Ser. No. 14/754,443, filed 29 Jun. 2015, which claimspriority to U.S. Provisional Application Ser. No. 62/111,087 filed Feb.2, 2015, entitled “Money Transfer By Use of a Universal Address,” andU.S. Provisional Application Ser. No. 62/073,844 filed Oct. 31, 2014,entitled “Money Transfer By Using a Tagging Mechanism,” which areincorporated herein by reference in entirety.

BACKGROUND

Payment transactions have become an important part of everyday life.With the widespread use of the Internet, it is becoming very convenient,and even desirable, for individuals to conduct payment transactionsonline. Solutions exist to enable electronic money transfers, e.g.,through Automated Clearing House (ACH) transfers, wire transfers, etc.However, these existing solutions are generally not designed to servicenon-sophisticated individuals and often involve a considerable amount oftime and activation energy to execute (e.g., account setup,username/password verification, etc.). Accordingly, even a simple act ofconveying and/or collecting money for an everyday life activity, e.g.,“IOUs,” donations from family and friends, etc., can become a burdensometask.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the disclosed technology will be described and explainedthrough the use of the accompanying drawings in which:

FIG. 1 illustrates an example of a network-based environment in whichsome embodiments of a payment proxy technology can be implemented;

FIG. 2 illustrates a data flow diagram of an overview of a moneytransfer process by use of a payment proxy within a forum context;

FIG. 3 illustrates a data flow diagram of an overview of a moneytransfer process by use of a payment proxy within a messagingapplication context;

FIG. 4 illustrates a data flow diagram of an overview of a moneytransfer process by use of a payment proxy within a landing pagecontext;

FIG. 5 is a flowchart illustrating an example process of transferringmoney by use of a payment proxy;

FIG. 6 is a flowchart illustrating an example process of linking a cardaccount for a transfer of money by use of a payment proxy;

FIG. 7 is a flowchart illustrating an example process of transferringmoney within a landing page context;

FIG. 9 illustrates example database tables coupled to the paymentservice system;

FIGS. 10A-10B illustrate various examples of graphical user interfacesfor emails received by recipients of money transfers;

FIG. 11 illustrates examples of graphical user interfaces for a landingpage and/or a website that enables a user to submit card information forassociating with the payment service system; and

FIG. 12 is a flowchart illustrating an example process 1200 oftransferring money (or cash payment) by use of a payment proxy;

FIG. 13 is a flowchart illustrating an example process 1300 of linking acard account for a transfer of money by use of a payment proxy;

FIG. 14 is a flowchart illustrating an example process 1400 oftransferring money within a landing page context;

FIG. 15 is a flow diagram illustrating an example method 1500 ofexecuting the cash tagging technology;

FIG. 16 illustrates an example of a processing system controller 1600with which some embodiments of the payment proxy technology can beutilized.

DETAILED DESCRIPTION

Technology is disclosed for simplifying a transfer of cash (i.e., money)between a sender and a recipient by use of a tagging mechanism (“thecash tag technology”). As used here, the term “tagging” refers to amarking of an alphanumeric character (or a string of alphanumericcharacters) to identify it (i.e., the character or string) for treatmentin a specified way. The term “alphanumeric character” as used hererefers to a symbol that can be a number (i.e., numeric), a letter (i.e.,alphabetic), or a combination thereof. Briefly described, the cash tagtechnology enables a sender, who desires to send cash to a recipient, totrigger a money transfer by specifying, in any communication message, anamount and a recipient using one or more inputs having a particularsyntax. The syntax includes a monetary currency indicator (or “currencyindicator”) prefixing one or more alphanumeric characters. The currencyindicator operates as the tagging mechanism that indicates to a computersystem to treat the inputs as a request from the sender to transfercash, where detection of the syntax (which includes one or morealphanumeric characters tagged by a monetary currency indicator)triggers a transfer of cash. The currency indicator can correspond tovarious currencies, e.g., dollar ($), euro (€), pound (£), rupee (

), yuan (v), etc. Although use of the dollar currency indicator ($) isused herein, it is to be understood that any currency symbol couldequally be used.

Today, money transferring solutions typically require some form ofregistration by both parties involved in the transaction (i.e., a senderand a recipient of the payment) before the payment transfer can occur.The registration generally includes an account creation process and alogin verification process. In particular, a sender must (a) entervarious account information, e.g., name, address, email address, etc.,to create an account with a particular payment service, and (b) wait fora verification email to verify the sender's identity associated with thenewly created account, for example, by clicking on a web addressincluded in the verification email to enter various authenticationcredentials, e.g., login name, password, etc. Some existing solutionsalso require verification of the banking institution(s) linked to theaccount, e.g., verify authentication amount deposited in the sender'sbank account. Furthermore, to transfer money to the recipient, thesender generally must know at least some financial account informationof, or other identifier for, the recipient, e.g., a bank account number,a routing number, a telephone number, an email address, etc.

In contrast, the cash tag technology introduced here provides efficientexecution of financial transactions (e.g., payment transfers) byenabling a sender to trigger a money transfer through the use of thesyntax in any communication message. In particular, the sender canspecify, in a communication message, an amount of money to transfer byincluding an input having the syntax, where the input can include themonetary indicator and one or more numeric characters (e.g., $10). Insome instances, the sender can also specify, in the communicationmessage, the recipient to whom the sender intends to send the money byincluding another input having the syntax. The input can include themonetary indicator and one or more alphabetic and/or numeric characters(e.g., $alex or $alex123). Such input identifying the recipient isreferred to as a “payment proxy” in this description, as shorthand.

A computer system, upon receiving indication of the sender's desire formoney transfer (i.e., as indicated by the input(s) having the syntax),initiates the money transfer on behalf of the sender (i.e., executes, orcauses to be executed, one or more operations to transfer funds betweenthe appropriate accounts). The transfer can be initiated irrespective ofthe financial institution with which the sender or the recipient isassociated. For example, the cash can be transferred even though thesender may have a financial account associated with Bank A while therecipient may have a financial account associated with Bank B.Furthermore, the computer system can initiate the transfer regardless ofthe bank-acquirer-financial institution structure associated with therecipient. Once the payment proxy is provided, the computer system canidentify the associations and establish the communication links toinitiate the transfer. Additionally, the computer system executes, orcauses to be executed, the transfer in such a way that neither thesender nor the recipient is privy to sensitive information about eachother. In particular, the computer system can encrypt financialinformation and any other personal identifying information (e.g., emailaddresses, phone numbers, usernames, payment proxies, etc.), therebysecuring payment transaction(s) between the sender and the recipient andkeeping all information “hidden” from the respective parties. Thecomputer system can also shield such information from financialinstitutions (e.g., banks) that may otherwise target products and/orservices using any known information of the parties (e.g., personalidentifying information).

As will be discussed in further details below, the cash tag technologycan be implemented in a variety of contexts. In some embodiments, thecash tag technology can be implemented within a forum context. The term“forum,” as used here, refers to a content provider's media channel(e.g., a social networking platform, a microblog, a blog, video sharingplatform, a music sharing platform, etc.) that enables user interactionand engagement through comments, posts, messages on electronic bulletinboards, messages on a social networking platform, and/or any other typesof messages. The forum can be employed by the content provider to enableusers of the forum to interact with one another, e.g., through creatingmessages, posting comments, etc. In some embodiments, forum may alsorefer to an application or webpage of an e-commerce or retailorganization that offers products and/or services. Such websites canprovide an online “form” to complete before or after the products orservices are added to a virtual cart. The online form may include one ormore fields to receive user interaction and engagement. Examples includename and other identification of the user, shipping address of the user,etc. Some of these fields may be configured to receive paymentinformation, such as a payment proxy, in lieu of other kinds of paymentmechanisms, such as credit cards, debit cards, prepaid cards, giftcards, virtual wallets, etc.

Within a forum context, the cash tagging technology involvescommunication between a sender's processing device, a computer systememployed by the content provider and a computer system employed by apayment service (hereinafter, a “payment service system” or “PSS”). Thepayment service system, in coordination with the computer system of thecontent provider, monitors messages, comments, forms, and/or posts atthe forum (or referred to here and throughout as “forum messages” forsimplicity) to detect an indication of an intent to transfer money to arecipient. In particular, the computer system of the content providercan parse forum messages to identify a specified syntax associated withany user input included in any of the forum. Upon identification of thespecified syntax in a particular forum message, the computer system ofthe content provider, communicating via an application program interface(API) associated with the payment service system, can notify the paymentservice system. For example, the computer system of the content providercan transmit a notification message over a network to the paymentservice system, where that notification message includes informationabout one or more inputs in the particular forum message that have thesyntax. An input having the syntax can be an input that indicates anamount of money (e.g., $10), or an input representative of a paymentproxy (e.g., $alex) that identifies a recipient of money. Upon receivingnotification message, the payment service system identifies the amountof money and the recipient for the money transfer based on informationin the notification message. The payment service system can identify therecipient based on the payment proxy (if one is included) or based onanother identifier of the recipient (e.g., email address, username,phone number, etc.) that is part of the forum message. The paymentservice system can further identify a recipient financial account of therecipient by mapping the recipient's identifier to the financial accountusing association data stored in a database. That database can be adatabase of the payment service system (e.g., where the identifier is apayment proxy), or a database of the content provider (e.g., where theidentifier is a username associated with the content provider). Afterthe recipient financial account is identified, the payment servicesystem can initiate, or trigger initiation, of a transfer of fundsindicative of a payment amount from a sender financial account to theidentified recipient financial account.

Consider an example scenario where a user sender can indicate an intentto transfer money by specifying, in a forum message that the user“posts” on a microblog of The Red Cross®, “Here is my support of $10.”In such an example, the microblog can discover the user's intent to sendmoney, e.g., by parsing the message, based on an identification of thesyntax in the input “$10.” Note that the parsing can be performed, forexample, by a browser client. Alternatively, the parsing can beperformed by a server in communication with the browser client. Forexample, all forum messages at the microblog are transmitted to theserver which performs the parsing, among other functionalitiesassociated with the microblog.

In another example scenario, the user can post a forum message on avideo sharing platform, where the forum message can include an inputthat identifies the recipient, e.g., “$funnyguy311, great content! Hereis my support for 10.” In such example, the video sharing platform candiscover the user's intent based on a parsing of the forum message andresulting identification of the syntax in the payment proxyIfunnyguy311.” The video sharing platform can notify the payment servicesystem by forwarding the content of the forum message (e.g., a portion,or all, of the information parsed from the forum message). The videosharing platform can also recognize the monetary amount of “10” intendedto be transferred to the recipient and forwards this information to thepayment service platform. Alternatively, this amount can be identifiedby the payment service system upon receiving the content of the forummessage.

Upon receiving the content of the forum message, the payment servicesystem can identify the recipient financial account for the moneytransfer by mapping the payment proxy included in the message (e.g.,“$funnyguy311”) to the recipient financial account, based on associationdata stored in the payment service system's database that maintainsinformation of users of the payment service. In instances where thepayment proxy is not included (e.g., the microblog example), the paymentservice system can identify the recipient financial account by mapping adifferent identifier of the recipient (e.g., username associated withthe forum provided by the content provider) with the recipient financialaccount. For example, the payment service system communicates with thecontent provider's database storing information about users of thecontent provider.

Similarly, the payment service system can identify the sender financialaccount by mapping an identifier of the sender with the sender financialaccount. The identifier of the sender (“sender identifier”) can beidentified based on who is currently accessing the forum, e.g., using abrowser client. For example, the browser client identifies the user thatis currently logged in and communicates that information to the paymentservice system. Alternatively, the sender identifier can be identifiedbased on new login credentials submitted by the sender (e.g., entered atthe forum and/or at an interface associated with the payment servicesystem and presented via the forum). Upon identification of both thesender and the recipient financial accounts, the payment service systemtransfers, or causes, to be transferred, the funds indicative of theamount to the recipient financial account.

Within the context of a forum being an online shopping portal, the cashtag technology involves providing one or more form fields to receive apayment proxy, instead of financial information of a payment card. Oncethe payment proxy is submitted as a mechanism for payment, a transfer offunds from a sender to a recipient can be confirmed by a notification tothe sender device, e.g., via a text message, a push message or a phonecall made out to a phone number associated with the sender device. Thetext or push message may have hyperlinks for the user to select orinteract with in order to approve the payment. The phone call mayrequest answers to security questions to approve the payment.Alternatively, an interactive webpage may be provided to obtainadditional information to secure the transaction.

In some embodiments, the cash tag technology can be implemented within acommunication application context, such as a messaging applicationcontext. The term “messaging application,” as used here, refers to anymessaging application that enables communication between users (e.g.,sender and recipient of a message) over a wired or wirelesscommunications network, through use of a communication message. Themessaging application can be employed by a messaging service providerthat delivers a communication service to users, e.g., chat or messagingcapability. The messaging application can include, for example, a textmessaging application for communication between phones (e.g.,conventional mobile telephones or smartphones), or a cross-platforminstant messaging application for smartphones and phones that use theInternet for communication. The messaging application can be executed ona user's computing device (e.g., mobile device or conventional personalcomputer (PC)) based on instructions transmitted to and from a messagingcomputer server system (“messaging server”). In some instances, themessaging application can include a payment application with messagingcapability that enables users of the payment application to communicatewith one another. In such instances, the payment application can beexecuted on the user's computing device based on instructionstransmitted to and from a computer server system employed by a paymentservice (e.g., the payment service discussed in this description oranother payment service that supports payment transactions).

Within a messaging application context, the cash tagging technologyinvolves communication between a messaging application executing on auser's mobile device, a payment application also executing on the mobiledevice, and a remote payment service system (PSS). Consider an examplescenario where a sender user (or simply, “sender”) launches a mobilemessaging application executing on her mobile device (e.g., a smartphoneor a tablet computer) to send a message to a recipient. For example, thesender inputs a telephone number of the recipient in a “TO” field of auser interface of the mobile messaging application to send a textmessage to the recipient. Although a text message is used as an examplehere, it is to be understood that the cash tag technology may employ anytype of message, including, for example, a chat message, an emailmessage, or indeed any other type that is capable of being exchangedbetween computing devices.

The sender can proceed to compose a message (or note in the body of themessage) to the recipient by including, among other things, an inputthat contains a monetary currency indicator prefixing a numericcharacter (e.g., “Here is the $10 I owe you. Thanks.”). The mobilemessaging application can parse the message to detect that the input hasthe syntax that includes a monetary currency indicator prefixing analphanumeric character. In response, the mobile messaging applicationcan identify the recipient to whom the message is being sent (e.g.,based on the telephone number), identifies the amount desired by thesender to be sent to the recipient (e.g., based on the numericcharacter(s) of the input), and communicates that information to thepayment application, which in turn communicates with the PSS forprocessing the money transfer.

In some embodiments, the mobile messaging application determinesidentification information associated with the recipient on behalf ofthe PSS by communicating with the messaging server. In such embodiments,the mobile messaging application, for example, can send a request to themessaging server, where the request includes a unique ID/username of therecipient. The messaging server can perform a database lookup based onthat username. In this example, the messaging server computer system candetermine whether the username is associated with any identificationinformation (e.g., an email address, a telephone number, etc.). Themessaging server can send that identification information back to themobile messaging application, which forwards it to the paymentapplication. In some embodiments, the server computer system directlysends the identification information of the recipient to the PSS.

In some embodiments, the second input is associated with a contact entryin a contacts list stored at the sender's mobile device. In suchembodiments, the mobile messaging application searches the contacts listto determine identification information associated with the recipient,and forwards that information to the PSS.

In some embodiments, the mobile messaging application sends the entiretext message to the messaging server, which performs the parsing anddetection of the syntax. In such embodiments, the messaging serverdetermines recipient's identification information and transmits thenotification (along with the identification information) to the PSS. Asused here, the identification information of the recipient (“recipientinformation”) can be an identifier (e.g., an email address, a telephonenumber, a device ID, etc.) or other identifying information (e.g.,mailing address).

Upon receiving the notification, the PSS (and/or the payment applicationbased on instructions from the PSS) can cause a movement, or transfer,of money, based on information included in the notification, withoutrequiring an explicit command (e.g., from the sender) to transfer themoney; so long as the currency indicator is detected, the money transfercan be executed and/or triggered to be executed. To initiate the moneytransfer, the PSS can analyze information about the recipient identifiedin the TO field (e.g., based on phone number, email address, username,etc.). The information can be received from the messaging server and/orthe messaging application to enable the PSS to identify the recipientand the recipient financial account of that recipient.

In some embodiments, the sender can indicate an intent to transfer moneyby including a second input in the TO field of the message; moreparticularly, the sender can specify a payment proxy in the TO field.For example, the user enters into the TO field “$redcross.” In anotherexample, the user enters into the TO field “$aaron.” The second inputoperates as a unique identifier (ID) or an avatar that identifies therecipient without disclosing recipient's information, such as bankinformation, email address, etc. The recipient can also personalize afinancial avatar for a foundation, organization, or business. Suchfinancial avatar can be provided, for example, to one or more senders ina public space, e.g., via a webpage (e.g., Donate money by sending it tothe $Foundation!” For example, the second input can be“$donatetoredcross” where recipient named Aaron may be requesting moneyfor a Red Cross® project.

Once the user enters the payment proxy, or input having the syntax, intothe TO field, composes a note for the message body, e.g., “Here is 10,”and sends the message using the messaging application (e.g., by clicking“Send”), the process continues in a similar path as discussed above.That is, in some instances, the messaging application communicates themessage to the messaging server, which performs the parsing anddetection of the payment proxy in the TO field, and communicates atleast a portion of the message to the PSS. In other instances, themessaging application performs the parsing to detect the syntax of thepayment proxy in the TO field, and communicates at least a portion ofthe message to the payment application, which can then communicate withthe payment service system for processing the money transfer. Theportion of the message can include, for example, the parsed recipientidentifier “redcross” and/or the numerical value of the money intendedto be sent to the recipient (e.g., 10).

Upon receiving information about the money transfer request (e.g., fromeither the payment application or the messaging server), the paymentservice system can identify a recipient associated with the input thatis derived from the TO field, and further identifies a recipientfinancial account associated with that recipient. In some embodiments,the PSS accesses a username database to identify for a database entrythat matches the alphabetic portion of the second input, and determineswhether that database entry is associated with payment card informationthat identifies a payment card of the recipient. Upon identifying thepayment card based on the second input, the PSS causes funds to betransferred to the recipient financial account, where that financialaccount is associated with the identified payment card. The payment cardcan be, for example, a debit card, and the financial account can be, forexample, a debit account associated with the debit card.

In some embodiments, if the PSS is unable to identify a database entrythat matches the second input, the PSS sends a message to the mobilemessaging application requesting identification information of therecipient. In some embodiments, the mobile message application, uponreceiving the request from the PSS, prompts the sender to provide theidentification information of the recipient. The mobile messagingapplication can then forward the identification information to the PSS,which sends a message, based on the identification information, toprompt the payment card information from the recipient. In someembodiments, the mobile messaging application communicates with amessaging server facilitating the mobile messaging application to obtainthe identification information.

In some embodiments, the PSS itself communicates with the messagingserver to obtain the recipient's identification information and/or thepayment card information. In some embodiments, the PSS directlycommunicates with the messaging server to connect with the recipient forthe payment card information. In such embodiments, the PSS sends arequest to the messaging server to transmit a message to the recipient,where the message prompts the recipient to provide payment cardinformation for processing the sender's requested money transfer. Themessage can include, for example, a link that can be accessed toredirect the recipient to a landing page, at which the recipient cansubmit the payment card information. The messaging server, based on theusername of the recipient received from the PSS, can perform a databaselookup to determine if that username is associated with identificationinformation of the recipient (e.g., a device identifier (“device ID”),an application identifier (“app ID”), an email address, a telephonenumber, etc.). The server, based on the determined identificationinformation, sends the message to the recipient to prompt for thepayment card information. The message can be sent, for example, via aninstant message within an instant messaging application executing on therecipient's computing device (e.g., a desktop computer or a mobiledevice such as a smartphone). In another example, the message can besent via a push notification to the recipient's computing device.

In at least some embodiments, the cash tag technology can be implementedwithin a landing page context. The term “landing page,” as used here,refers to a virtual location identified by a personalized locationaddress that is dedicated to collect payments on behalf of a recipientassociated with the personalized location address. The personalizedlocation address that identifies the landing page can include a paymentproxy discussed above. The payment service system generates the landingpage to enable the recipient to conveniently receive one or morepayments from one or more senders.

In some embodiments, the personalized location address identifying thelanding page is a uniform resource locator (URL) that incorporates thepayment proxy. In such embodiments, the landing page is a web page. Forexample, the URL is www . . . com/$CharityName, which identifies thelanding page as a web page dedicated to collecting money forCharityName. In another example, the URL is www . . . com/$aaron. Asender can access the landing page, e.g., by entering the URL into a webbrowsing application installed, or executing, on the sender's clientdevice. Upon navigating to the URL, the sender can simply enter apayment amount, e.g., in a web entry field, and send the money, e.g., byselecting a “Pay” action button displayed on the web page. In someembodiments, the URL can include a fixed payment amount, in addition tothe payment proxy. For example, the URL is www . . .com/$CharityName$20. The fixed payment amount included in thepersonalized URL can be specified by the recipient, and designed torequest that fixed amount from any sender that accesses the landing pageidentified by the URL.

In some embodiments, the landing page is identified by a graphical userinterface (GUI) of a mobile payment application installed on a clientdevice of the sender. The GUI can be dedicated to a main payment proxy,where there can be multiple GUIs each dedicated to a different paymentproxy associated with that main payment proxy. For example, the sendercan access the landing page by selecting, within a mobile paymentservice application, a GUI labeled with the payment proxy $CharityNamerepresentative of a charity group, and further select another GUIlabeled $Research to make a donation to the Research subgroup atCharityName. For example, the sender can enter a payment amount at the$Research GUI and select a “Pay” action button displayed at that GUI.

Various embodiments will now be described in further detail. Thefollowing description provides specific details for a thoroughunderstanding and enabling description of these embodiments. One skilledin the relevant art will understand, however, that the embodimentsdiscussed herein may be practiced without many of these detailsLikewise, one skilled in the relevant art will also understand that theembodiments can include many other obvious features not described indetail herein. Additionally, some well-known structures or functions maynot be shown or described in detail below, so as to avoid unnecessarilyobscuring the relevant description.

The terms “connected” or “coupled” and related terms used throughout thedescription are used in an operational sense and are not necessarilylimited to a direct physical connection or coupling. Thus, for example,two devices may be coupled directly, or via one or more intermediarymedia or devices. As another example, devices may be coupled in such away that information can be passed there-between, while not sharing anyphysical connection with one another. Based on the disclosure providedherein, one of ordinary skill in the art will appreciate a variety ofways in which connection or coupling exists in accordance with theaforementioned definition.

The phrases “in some embodiments,” “according to some embodiments,” “inthe embodiments shown,” “in other embodiments,” and the like generallymean the particular feature, structure, or characteristic following thephrase is included in at least one implementation of the disclosedtechnology, and may be included in more than one implementation. Inaddition, such phrases do not necessarily refer to the same embodimentsor different embodiments.

The term “module” or “engine” refers broadly to general orspecific-purpose hardware, software, or firmware (or any combinationthereof) components. Modules and engines are typically functionalcomponents that can generate useful data or other output using specifiedinput(s). A module or engine may or may not be self- contained.Depending upon implementation-specific or other considerations, themodules or engines may be centralized or functionally distributed. Anapplication program (also called an “application”) may include one ormore modules and/or engines, or a module and/or engine can include oneor more application programs.

The term “cause” and variations thereof, as used throughout thisdescription, refers to either direct causation or indirect causation.For example, a computer system can “cause” an action by sending amessage to a second computer system that commands, requests or promptsthe second computer system to perform the action. Any number ofintermediary devices may examine and/or relay the message during thisprocess. In this regard, a device can “cause” an action even though itmay not be known to the device whether the action will ultimately beexecuted or completed.

Additionally, as used here, the term “parsing” refers to a process ofanalyzing a string of alphanumeric characters and/or symbols, forexample, in a natural language. In accordance with the embodiments ofthe cash tag technology, the parsing can be performed context-free orcontext-aware to determine intent of users from a sentence or phrase(e.g., in text of messages). In particular, parsing enables deriving asender's intent to transfer money by deconstructing a seemingly“innocent” (i.e., ordinary) message of the sender, such as “Here's $10,”to mean, e.g., “Sender wishes to send $10.” Such deconstruction can becoupled, optionally in some embodiments, with a creation of a hyperlinkfor the “$10” included in the message to enable money transfer byfollowing the link. For example, interaction with the hyperlinkindicates an approval for the PSS to initiate the money transfer. Inanother example, the hyperlink redirects the sender to a webpage forcompleting the money transfer with the PSS.

The message deconstruction involved in parsing can include analyzing theparticular context involved in the message. For example, the message“Here's $10!” can be treated differently from “Hey, I got youcovered—paid Betty $20 yesterday for next week's event!” based on ananalysis of the context. By parsing with context, it can be derived thatthe prior message in the example would require a money transfer whilethe latter would not. The context (and intent) can be determined basedon a statistical parsing model (e.g., learning machine). The model canrely on a 2corpus of training data to gather information about thefrequency on which various constructions occur in specific contexts.Such frequency can be used to determine a probability of whether theintent derived from the text is accurate. For example, the probabilityof the user having such an intent can be measured based on whether theprobability meets or exceeds an acceptability threshold. Furthermore,related messages (e.g., nearby messages posted by other users on thesame forum, past messages composed by the same user in the past, nearbymessages composed by other users within a geographical distance from thecurrent user, etc.) can be utilized in making a context-baseddetermination of the intent to transfer money.

The term “payment card,” as used in the above examples and throughoutthe description, refers to a payment mechanism that includes aconventional debit card, a conventional credit card, a prepaid giftcard, or the like, a smartcard that has an embedded integrate circuitchip (e.g., Europay-MasterCard-visa (EMV) card), a proxy card, or anycard that functions as a combination of any of these mechanisms. Theterm “proxy card” as used herein refers to a card that bears a cardnumber/account number that appears to be that of a real credit or debitcard account (i.e., it is in the correct format), but where thatcard/account number is actually only a proxy for the customer's realcard/account number. Additionally, the payment card used in the exampleabove is a specific type of a financial instrument. Other types offinancial instruments, other than the payment card, can be used toinitiate the transfer of cash. An example of another type of a financialinstrument is a biometrically identifiable instrument, such as aperson's finger (e.g., for fingerprint recognition), face, iris orretina, heartbeat, etc. Alternatively, a financial instrument can be asoftware instrument or virtual instrument, such as a virtual wallet.

It is noted that while the sender in the embodiments discussed aboveuses a mobile device, in other embodiments, the sender may use acomputing device other than a mobile device to utilize the cash tagtechnology, such as a conventional desktop computer. In suchembodiments, the mobile messaging application can be replaced by a moreconventional software application in such computing device, where thesoftware application has functionality similar to that of the mobilemessaging application as described in the above example scenario.

It is also noted that the cash tag technology is equally applicable inother embodiments to various other content providers and various othertypes of providers, such as financial service providers or to anyapplication that involves communication of messages between users, andthat the universal address technology is not limited to media channelsand/or messaging applications. Furthermore, the cash tag technology canbe implemented with other non-cash transfers, e.g., payment card points,airplane miles, etc., and is not limited to transfers of money.

Moreover, the cash tag technology introduced here can be embodied asspecial-purpose hardware (e.g., circuitry), as programmable circuitryappropriately programmed with software and/or firmware, or as acombination of special-purpose and programmable circuitry. Hence,embodiments may include a machine-readable medium having stored thereoninstructions that may be used to cause one or more processors to performthe methods, variations of the methods, and other operations describedhere. The machine-readable medium may include, but is not limited to,floppy diskettes, optical discs, compact disc read-only memories(CD-ROMs), magneto-optical discs, read-only memories (ROMs), randomaccess memories (RAMs), erasable programmable read-only memories(EPROMs), electrically erasable programmable read-only memories(EEPROMs), application-specific integrated circuits (ASICs), magnetic oroptical cards, flash memory, or other type of media/machine-readablemedium suitable for storing electronic instructions.

Turning now to the Figures, FIG. 1 illustrates an example of anetwork-based environment 100 in which some embodiments of the cash tagtechnology can be implemented. The embodiments illustrated in FIG. 1include a client device 102, a computer server system 104 of athird-party web content provider (“web server 104”), a computer serversystem 106 of a third-party application service (“application server106”), and a computer server system 110 of a payment service (“paymentservice system 110” or “PSS 110”), all of which are in communicationover a communication network 108. In some embodiments, the PSS 110includes one or more servers 112 and an Application ProgrammingInterface API 114 (“API 114”). The one or more servers 112 are typicallyequipped with, or is coupled to, one or more databases 116 (“DB 116”),which can include one or more hard drives, a centralized or distributeddata cluster, a cloud-storage service provider, or other suitablestorage systems suitable for storing digital data.

It should be noted that in other embodiments, the environment 100 canhave more or fewer components than shown, or a different configurationof components. The various components shown in FIG. 1 can be implementedby using hardware, software, firmware or a combination thereof,including one or more signal processing and/or application specificintegrated circuits. Further, the environment 100 of FIG. 1 can beimplemented based on other architectures in other embodiments. Forexample, in some embodiments, the API 114 can exist separately from thePSS 110, e.g., as part of the web server 104 or the application server106, or as a standalone server (e.g., a standalone API server incommunication with the web server 104, the application server 106, andthe servers 112). In another example, in some embodiments, functions ofat least some of the servers can be consolidated.

The network 108 can include any combination of local area and/or widearea networks, using both wired and wireless communication systems. Insome embodiments, the network 108 uses standard communicationstechnologies and/or protocols. Thus, the network 108 can include linksusing technologies such as Ethernet, 802.11, worldwide interoperabilityfor microwave access (WiMAX), 3G, 4G, CDMA, digital subscriber line(DSL), etc. Similarly, the networking protocols used on the network 108may include multiprotocol label switching (MPLS), transmission controlprotocol/Internet protocol (TCP/IP), hypertext transport protocol(HTTP), and/or file transfer protocol (FTP). Data exchanged over thenetwork 108 can be represented using technologies and/or formatsincluding hypertext markup language (HTML) or extensible markup language(XML). In addition, all or some links can be encrypted usingconventional encryption technologies such as secure sockets layer (SSL),transport layer security (TLS), and Internet Protocol security (IPsec).

The client device 102 can be any processing device capable of receivinguser input as well as transmitting and/or receiving data via the network108. In some embodiments, the client device 102 can be a conventionalcomputer system (e.g., a desktop 102A or a laptop computer 102B) or amobile device having computer functionality (e.g., a tablet device 102C,a smartphone 102D, or a conventional mobile phone (not shown)). Theclient device 102 typically includes a display that can be used todisplay a user interface, and may include suitable input devices (notshown for simplicity) such as a keyboard, a mouse, or a touchpad. Insome embodiments, the display may be a touch-sensitive screen thatincludes input functionalities.

The client device 102 can be configured to communicate via the network108 with the web server 104 and/or the application server 106. In someembodiments, the client device 102 can retrieve or send information tothe web server 104 and/or the application server 106, and run one ormore applications with customized content retrieved from the web server104 or the application server 106. For example, the client device 102can execute a browser application to enable communication between theclient device 102 and the web server 104 (e.g., to access a socialnetworking website). In another example, the client device 102 canexecute a customized client to enable communication between the clientdevice 102 and the application server 106. For example, the customizedclient is a messaging application operated by a messaging server. Thecustomized client can further provide a channel of communication betweenrespective client devices of a sender user 140 (“sender 140”) and arecipient 142 (“recipient 142”) (e.g., a channel that enablestransmission of one or more electronic messages including, e.g., text,audio, and/or video). For example, the customized client enables aninstant exchange of electronic messages between the respective clientdevices. Other example messaging applications and/or messaging serverscan include an email application and email server or a social networkingmessaging application and a social networking server.

In accordance with various implementations of the cash tag technology,the sender 140 can utilize a given client device 102 to trigger a moneytransfer to a recipient 142. For example, by accessing a landing pagewith the client device 102, the sender 140 can submit an amount of moneyto the recipient 140 that is associated with the landing page. Inanother example, the sender 140, using the client device 102, cantransmit a message to the recipient (e.g., via a chat application or aforum), where that message includes an indication of an intent of thesender 140 to send money to the recipient through use of a specifiedsyntax for one or more inputs in that message. The recipient 142 cansimilarly use another given client device 102 to receive the money, forexample, by interacting with a confirmation link sent to the clientdevice of the recipient 142 as a result of the money transfer triggeredby the sender 140.

The web server 104 can host a website (hereinafter, “system website”)that includes one or more graphical user interfaces (GUIs) fororganizing and presenting content to users. For example, through thesystem website, users create account logins to connect to their socialidentities (e.g., social profiles or social accounts or shoppingaccounts), read content (e.g., messages, comments, posts), create orpost content, communicate in real-time with other users (e.g., chat,post messages, comment on posts, etc.), and/or otherwise engage orinteract with other users of the system website (e.g., “friends,”“followers,” “social contacts,” or other types of social networkconnections). In some embodiments, the user interactions on the systemwebsite lead to internal API communication, which involves the webserver 104 monitoring the user interactions for an indication of anintent to transfer money, e.g., by parsing messages at the systemwebsite. In response to such indication, the web server 104 can transmitone or more requests (e.g., POST or GET requests) to the API 114 of theserver(s) 112 to query the database(s) 116, and display the datareturned by the API 114 of the server(s) 112 as appropriate. The webserver 104 can determine the indication of the intent based on anidentification of a user input, e.g., a string of characters, that has aparticular syntax, the syntax being a monetary indicator preceding oneor more alphanumeric characters. The user input having the syntaxoperates as a trigger to send money to a particular recipient (e.g.,recipient 142). The recipient can be identified based on a user inputwith the syntax (i.e., payment proxy represented by the user input), orbased on a user account of a user currently accessing the system website(e.g., login credentials).

In one example, the web server 104 monitors user messages on the systemwebsite for any particular message that includes a user input having thesyntax of the monetary indicator preceding the alphanumeric characters,and forwards a request to the API 114. In such an example, the webserver 104 can identify the syntax by parsing the user messages to find,for example, a message that includes the syntax, and further parses thatmessage to identify a payment amount and a payment proxy, and forwardssuch information to the API 114 and/or the server 112 to process themoney transfer. In some embodiments, the web server 104 parses the usermessages simply to identify any message with input(s) having the syntax,and forwards that message to the server 112 via the API 114. In suchembodiments, the server 112 can receive the message and can parse it fora payment proxy (i.e., one or more alphabetic characters of the userinput having the syntax) to identify a recipient associated with thepayment proxy. Upon identifying the recipient, the server 112 canidentify an associated recipient financial account, and initiate a moneytransfer to that recipient financial account. In some embodiments, theAPI 114 (e.g., instructed by the server 112) can also send back, in aresponse to the web server 104, appropriate data for display to theuser. For example, the data is an HTML string that displays aconfirmation message with a link for prompting the sender to confirmhis/her intent to transfer money to the recipient associated with thepayment proxy. In some embodiments, the server 112 sends a confirmationmessage to the sender using information included in the request receivedfrom the web server 104, e.g., an identifier associated with the sender.For example, the identifier can be an email address of the user, and theserver 112 (e.g., via an email server) sends an email message to theuser's email address.

The application server 106 supports an application (hereinafter, “systemapplication”) that includes one or more graphical user interfaces fororganizing and presenting content to users. The system application canbe a mobile application installed on a mobile device or a conventionalsoftware application installed on a conventional personal computer.Users can utilize the system application to interact with other users.The system application can be a messaging application. For example,through the system application, users create account logins to connectto their social identities (e.g., social profiles or social accounts orshopping) to communicate with other social identities, read messages,create or post messages, communicate in real-time with other users(e.g., chat), and/or otherwise engage or interact with other users ofthe system application (e.g., “friends,” “social contacts,” or othertypes of social network connections). In some embodiments, the userinteractions on the system website lead to internal API communication,which involves the application server 106 monitoring the messages for anindication of an intent to transfer money, e.g., by parsing messages atthe system application. In response to such indication, the applicationserver 106 can transmit one or more requests (e.g., POST or GETrequests) to the API 114 of the server(s) 112 to query the database(s)116, and display the data returned by the API 114 of the server(s) 112as appropriate. In some embodiments, it is the system application thatperforms the parsing. Upon identifying the syntax, the systemapplication can notify the application server 106 of the indication ofthe intent to transfer money. Alternatively, in some embodiments, thesystem application notifies a payment service application executing onthe user's device of the indication, where that payment serviceapplication communicates with the servers 112 via the API 114.

In one example, the system application monitors at the user device(e.g., client device 102 of the sender 140) for any particular messagethat includes a user input that has the syntax of the monetary indicatorpreceding the alphanumeric characters. Upon identifying such a message,the system application notifies the application server 106, whichtransmits a request to the API 114 that includes, e.g., the message andan identifier associated with a creator of the message (e.g., an emailaddress), for the API 114 and/or the server 112 to process the moneytransfer. In such an example, the server 112 can parse the message for apayment proxy (i.e., the user input having the syntax) to identify arecipient associated with the payment proxy. Upon identifying therecipient and an associated recipient financial account, the server 112initiates a money transfer to that recipient. In some embodiments, thesystem application communicates with a payment service applicationexecuting at the user's device via an API call (e.g., through API server114). The payment service application can then further parse theidentified message having the syntax to identify an amount of money forthe transfer and a recipient for the transfer (e.g., payment proxy). Thepayment service application can communicate this information to theserver 112 (e.g., via the API server 114), which processes the moneytransfer based on this information. In some embodiments, the paymentservice application forwards the message to the server 112, whichperforms the additional parsing to identify the amount of money and therecipient.

In some embodiments, the API 114 (e.g., instructed by the server 112)can also send back appropriate data relating to the money transfer fordisplay to the user at the system application. For example, the dataincludes text that can be incorporated in, e.g., a push notification,that displays a confirmation message with an action link for the user toconfirm his/her intent to transfer money to the recipient associatedwith the payment proxy. In some embodiments, the server 112 sends aconfirmation message to the user using information included in therequest received from the application server 106, e.g., an identifierassociated with the user. For example, the identifier can be a telephonenumber of the user, and the server 112 sends a text message to theuser's phone number.

The PSS 110 can be a cloud computing environment, a virtualizedcomputing environment, a computer cluster, or any combination thereof.The PSS 110 includes a payment processor (not shown) configured toprocess money transfers conducted between a sender and a recipientidentified by a payment proxy. As discussed briefly above, the PSS 110includes the one or more servers 112. The payment processor can be apart of the one or more servers 112, and can work in coordination withthe API 114 to exchange requests and responses with the Web server 104,the application server 106, and/or the payment service applicationassociated with the PSS to process one or more transactions triggered byuse of the syntax (e.g., money transfers). The one or more servers 112can handle secure transactions (e.g., using a secure server), to processall payment transactions triggered.

In general, the servers 112 store secure information such as credit cardnumbers, debit card numbers, bank accounts, user accounts 118, e.g.,payment proxies associated with users, user identifying or profileinformation, financial account information, or other sensitiveinformation. Each user account 118 can be associated with one or morecard accounts of the user, e.g., debit or credit card accounts. A cardaccount can be a financial account managed by a card issuer (e.g., acard issuer 132) and can be associated with the card number. In someembodiments, the one or more card accounts are stored at the server 112(e.g., at the DB 114). Generally, the card issuer issues physicalpayment card for each card account.

In some embodiments, the PSS 110 includes a payment service applicationserver (e.g., a server of the servers 112) that supports a paymentapplication for executing various services provided by the PSS(hereinafter, “payment service application”). The payment serviceapplication includes one or more graphical user interfaces forpresenting content and processing user requests. The payment serviceapplication can be a mobile application (i.e., “mobile paymentapplication”) installed on a mobile device or a conventional softwareapplication installed on a conventional personal computer. For example,through the payment service application, users create account logins toutilize financial services offered by the PSS 110, to link theirfinancial accounts with the payment service system 110 (e.g.,registration with the PSS 110), to transfer money using their useraccounts and/or financial accounts, and/or otherwise engage with theservices offered by the PSS 110 via the payment service application.

To process payment transactions, the PSS 110 can communicate with one ormore financial networks. In some embodiments, the PSS 110 cancommunicate with a computer system 120 of a card payment network, e.g.,a debit card payment network (e.g., STAR or PULSE) or a credit cardpayment network (e.g., Visa® or MasterCard®), (collectively, “cardpayment network 120”). In some embodiments, the PSS 110 can communicatewith the card payment network 120 over the same network 108, or adifferent network. In one example, the card payment network 120 cancommunicate, in turn, with the computer system 122 of a sender cardissuer, e.g., a bank, and a computer system 124 of a recipient cardissuer, e.g., a same or different bank. The sender card issuer 122 andthe recipient card issuer 124 can transfer money, e.g., over a debitpayment network, in response to a request to transfer money from the PSS110.

In some embodiments, the PSS 110 can communicate with a computer system130 of an Automated Clearing House (ACH) network. The computer system130 of the ACH network can communicate with a sender bank account 132and a recipient bank account 134. The sender bank account 132 and therecipient bank account 134 can transfer money, e.g., using the ACHnetwork, in response to a request to transfer money from the PSS 110. Inother embodiments, there can also be computer systems of other entities,e.g. the card acquirer, between the PSS 110 and the card issuers, andbetween the PSS 110 and the bank accounts.

In accordance with various embodiments, a payment transaction (e.g., atransferring of money) can originate at a device of the sender 140(“sender device”), such as the desktop 102A. For example, the sender 140can initiate a payment transaction by using the sender device to accessand/or interact on a forum, such as a microblog hosted by the web server104. Alternatively, the sender 140 can initiate, for example, thepayment transaction by using the sender device to access a landing pagethat is associated with a personalized URL, which incorporates a paymentproxy of the recipient 142. In another example, the sender 140 caninitiate a payment transaction by using a sender device to access anapplication such as a messaging application supported by the applicationserver 106. In yet another example, a user can initiate a paymenttransaction by using a sender device to access an application such asthe payment service application supported by the PSS 110.

The PSS 110 can process the payment transaction on behalf of the user.Processing the payment transaction involves identifying a financialaccount of a sender user and a financial account of a recipient user(e.g., by accessing the DB 116 of the PSS 110).

In accordance with various embodiments of the disclosed technology, thefinancial account of the recipient user can be identified based on apayment proxy associated with the recipient user. For example, therecipient user may have previously created a payment proxy (e.g.,$redcross) to be used with a service provided by the PSS 110 (e.g., amoney transfer service), and entered financial account informationthrough a GUI (e.g., an interactive payment receiving interface) of thepayment service application of the PSS 110. In this example, the PSS110, in turn, associates the financial account information with therecipient user's newly created payment proxy in this registrationprocess. In other words, upon submission of information by the recipientuser, the PSS 110 automatically registers the financial account and thepayment proxy with the PSS 110 on behalf of the recipient user. Therecipient user can submit financial account information for one or morefinancial accounts. Associations of the one or more financial accountswith the recipient user's payment proxy can be stored on the PSS 110(e.g., DB 114). Information of the financial accounts can be used forfuture payment transactions (e.g., money transfers).

In accordance with various embodiments of the disclosed technology, thefinancial account of the sender user can be identified based onidentifier associated with the sender user (“sender identifier”). Insome embodiments, the PSS 110 can receive the sender identifier from theWeb server 104 or the application server 106. In some embodiments, thePSS 110 receives the sender identifier from the payment serviceapplication supported by the PSS 110.

The PSS 110 can identify a financial account of the sender user based onan association between that financial account and the sender identifier.For example, the sender user may have previously received payment (e.g.,from another sender user) and entered financial account informationthrough a GUI of the payment service application of the PSS 110 (e.g.,an interactive payment receiving interface). In such an example, the PSS110 may have identified the sender identifier of the sender user (e.g.,via email sent to the sender user or text message). In turn, the PSS 110stores the financial account information in association with the senderidentifier newly created by virtue of accepting the payment from theother sender user (using the service provided by the PSS 110). Thesender user can submit financial account information for one or morefinancial accounts. Associations of the one or more financial accountswith the sender identifier can be stored on the PSS 110 (e.g., DB 114).Information of these financial accounts can be used for future paymenttransactions (e.g., money transfers).

If no financial account information is identified for either the senderuser or the recipient user, the PSS 110 can send a message (e.g., afinancial account request message) to the respective user requestingthat financial account information to be submitted. The message can be aconfirmation message that includes a secure link to enter the financialaccount information, such as a debit card number or a credit card numberand associated authentication information (e.g., expire date, ZIP Code,PIN number, or security code). For example, the respective user cansimply input financial account information, such as a debit card numberor a credit card number.

When the financial account information is identified for both the senderuser and the recipient user (either initially or later submitted throughthe confirmation message), the PSS 110 sends a request to transfermoney, e.g. via the card payment network 120 or the ACH network 130. Inparticular, to transfer money between the sender user and the recipientuser (identified based on the payment proxy), the PSS 110 can operate asa gateway or a middleman.

To operate as a gateway, the PSS 110 can identify debit card accounts,e.g. stored at the servers 112, for both the sender user and therecipient user. The PSS 110 can submit a request to an appropriate cardissuer e.g., to the sender user's card issuer or to the receiving user'scard issuer, to transfer money. For example, the request can be sentover debit rails. That is, a debit card network can receive the requestand can carry out the request to transfer money. The appropriate cardissuer can receive and process the request by transferring money to theappropriate card account.

To operate as a middleman, the PSS 110 can receive a payment amount byprocessing a card, e.g., a credit card or a debit card, of the usersender and hold the payment amount. The PSS 110 can push the paymentamount, e.g., over debit rails, to a debit account of the recipientuser. Instead of holding the payment amount, the PSS 110 can alsoforward the payment once the recipient user links the account with thePSS 110. Alternatively, the PSS 110 can generate a transaction ACH thatdebits an amount from the sender bank account and can credit the amountinto a recipient bank account, e.g., using ACH, or onto a debit account,e.g., over debit rails, of the recipient user.

FIG. 2 illustrates a data flow diagram of a first example money transferprocess 200 within a messaging application context, in accordance withsome embodiments. The money transfer flow 200 begins at an instance ofan instant messaging application 202 executing on a mobile device (e.g.,smartphone) of a sender user (or simply, “sender”) named “Betty.”

The sender inputs a first message 210 to be sent to another user, or arecipient, named “Alex,” who can receive the first message 210 onanother instance of the instant messaging application (i.e., instantmessaging application 204) executing on his mobile device. The message210 includes one or more inputs from the sender (e.g., “Here is $10 forthe smoothie run”). The sender can interact with an action button 206(e.g., “Send”) on a user interface output by the mobile device (e.g.,based on instructions from the application 202) to send the message 210.The instant messaging application 202 can parse the message 210 anddetect that the message 210 includes an input 212 that contains “$10”,where the input 212 has a specified syntax of a monetary currencyindicator prefixing an alphanumeric character; that is, the input 212includes the currency indicator “$” and two numeric characters “1” and“0.”

The instant messaging application 202, in response to detection of theinput 212 having the syntax, generates a message 214 for display to thesender. The message 214 prompts a confirmation from sender that shewants to send an amount of money indicated in the message 210 (e.g.,$10) to the recipient of the message 210 (i.e., “Alex”). The sender caninitiate the money transfer to the recipient by selecting the “Yes”option displayed in the message 214.

In some embodiments, the PSS 110 causes the message 214 to be generatedin response to a detection of the input 212. In such embodiments, theinstant messaging application 202 first communicates a detection of thesyntax in the message 210 to a mobile payment application executing onthe sender's mobile device. For example, the messaging application 202causes a notification to be sent to the mobile payment application tonotify such detection of the syntax in the input 212. The notificationcan include information about the sender and the recipient of themessage 210 (e.g., user ID, device ID, application ID, instant messagingusername, etc.) and/or any other information about the message 210. Themobile payment application can then communicate with the PSS 110 toexecute, or trigger execution, of a money transfer based on thisinformation received from the messaging application 202. In someembodiments, before executing the money transfer, the PSS 110 sends amessage to the mobile payment application to instruct the instantmessaging application 202 to generate the message 214.

In some embodiments, the instant messaging application 202 sends thenotification to a remote server facilitating the instant messagingapplication 202 (i.e., a messaging server), which communicates thenotification to the PSS 110 (e.g., via an API call). The PSS 110, uponreceiving the notification from the messaging server, communicates withthe messaging server to instruct, or otherwise cause the instantmessaging application 202 to generate the message 214. In someembodiments, the instant messaging application 202 sends thenotification directly to the PSS 110, which then sends an instruction tothe instant messaging application 202 to generate the message 214.

In some embodiments, the instant messaging application 202, uponreceiving an indication to send the message 210 from the sender (e.g.,based on interaction with the action button 206), transmits the message210 to the messaging server. The messaging server then parses themessage 210 to detect the syntax and notifies the PSS 110. The PSS 110can then cause the message 214 to be displayed at the mobile device(e.g., by establishing communication links with the mobile devicethrough either the messaging server or the mobile payment applicationthat would communicate with the messaging application 202). In an eventwhere the messaging server does not detect any input having the syntax,the messaging server can proceed to process transmission of the message210 in accordance with typical messaging protocols.

Upon receiving the confirmation from the sender for the message 214, theinstant messaging application 202 sends the message 210 to the recipient(i.e., Betty), as indicated by message 216 displayed at the instantmessaging application 204 installed on the recipient's mobile device. Inparticular, the messaging application 202 can communicate theconfirmation with the messaging server, which forwards the message 210as message 216 displayed at the recipient's mobile device. In someembodiments, the instant messaging application 202 also communicates theconfirmation with the PSS 110. For example, the instant messagingapplication 202 can communicate with the messaging server (e.g., via anAPI call), which then communicates the confirmation to the PSS 110(e.g., via another API call). In another example, the instant messagingapplication 202 communicates with the mobile payment application (e.g.,through an API call to the mobile payment application); the mobilepayment application in turn can communicate with the PSS 110 throughanother API call about the confirmation.

The message 216 can further include a message 218, which can notify therecipient that the sender has sent money and instruct the recipient onhow to deposit that money (e.g., via a hyperlink). For example, thehyperlink included in the message 218 can redirect the recipient to alanding page, such as a webpage. An example of such a landing page isdisplayed in a graphical user interface 1102 of FIG. 11. Message 220 isan example of a message input by the recipient Betty to reply to thesender Alex notifying him that she has received the ten dollars. Message222 is an example of the message received from the recipient.

FIG. 3 illustrates a data flow diagram of a second example moneytransfer process 300 within a messaging application context, inaccordance with some embodiments. The money transfer flow 300 begins atan instant messaging application 302 installed on a mobile device (e.g.,smartphone) of a user, or a sender, named “Betty.”

The sender inputs a first message 310 to be sent to another user, or arecipient, named “Alex,” who can receive the first message 310 onanother instant messaging application 304 executing on his mobiledevice. The message 310 includes one or more inputs from the sender. Theinstant messaging application 302 detects (e.g., based on parsing themessage 210) that the message 310 includes an input 312 that contains“$10”, where the input 312 has a syntax of a monetary currency indicator“$” prefixing one or more numeric characters “10.” In contrast with thefirst example money transfer process 200 in the embodiments discussed inreference to FIG. 2, in the embodiments of FIG. 3, the second moneytransfer process 300 involves the instant messaging application 302transmitting the message 310 to the recipient upon submission by thesender (e.g., sender interacts with an action button by clicking“Send”), as opposed to generating a message prompting for confirmation(e.g., message 214 of FIG. 2).

The recipient can receive the message 310 as the message 314 displayedby the instant messaging application 304. In some embodiments, theinstant messaging application 302 causes at least a portion of the input312 to be emphasized on a user interface for the sender upon detectionof the syntax in the input 312 (e.g., bolded or highlighted textindicative of a monetary amount for money transfer). With the emphasis,the instant messaging application 302 can also associate a selectionaction 316 with a monetary amount represented by the emphasized portionof the input 312. The sender can initiate the money transfer byinteracting with the selection action 316 to confirm intent to transfermoney (e.g., click or touch the emphasized portion as displayed on theuser interface). Accordingly, such confirmation via the selection action316 triggers a process to transfer an amount that is associated with theselection action 316 (e.g., 10 dollars).

In response to the selection action 316, the instant messagingapplication 302 can generate a message 318 to prompt the sender forconfirmation. The message 322 can be a “pop-up” message or webpage thatdisappears upon selection of an action button by a viewer (e.g., therecipient). For example, the sender can select a “Send cash” actionbutton included in the message 322 to confirm the sender's intent tosend money by submitting the input 312. Alternatively, the sender canselect a “Cancel” action button included in the message 322 to cancelany initiation of the money transfer. The placement of the pop-upmessage is for discussion purposes only and may or may not be proximalto the last sent or received message.

Upon receiving the confirmation from the sender, the instant messagingapplication 302 sends a message 320 to the recipient (i.e., Betty)displayed at the instant messaging application 304. In some embodiments,upon receiving the confirmation, the instant messaging application 302first transmits, via a communications network, a message regarding theconfirmation to the messaging server. The messaging server can thencommunicate, via a same or different communication network, with the PSS110 regarding the confirmation received from the sender. The PSS in turncan transmit a return message to the messaging server, where the returnmessage is configured to cause the messaging server to transmit themessage 320 to the recipient's mobile device at the instant messagingapplication 304. In other embodiments, the instant messaging application302, upon receiving the confirmation (e.g., via interaction with themessage 318), communicates with the mobile payment application executingon the sender's mobile device. The mobile payment application thencommunicates with the PSS 110, which in turn, sends a return message tothe mobile payment application. The return message is configured tocause the mobile payment application to instruct the instant messagingapplication 302 to transmit the message 320 to the recipient's mobiledevice for display at the instant messaging application 304.

In some embodiments, the message 320 can be a pop-up message, as opposedto a message within the instant messaging application as shown theembodiment of FIG. 3. The message 320 further includes a hyperlink thatredirects the recipient to a landing page, such as a webpage. An exampleof such a landing page is displayed in a graphical user interface 1102of FIG. 11.

FIG. 4 illustrates a data flow diagram of a third example money transferprocess 400 that utilizes a payment proxy within a messaging applicationcontext, in accordance with some embodiments of the cash tag technology.The process 400 involves communication between a messaging application404 installed on a client device of the sender 401 (e.g., smartphone102D of FIG. 1), a computer server system 405 of the messagingapplication 404 (“messaging application system 405”), and the PSS 110.The messaging application system 405 can be, or include, the applicationserver 106 of FIG. 1 that is employed by, e.g., a messaging serviceassociated with a telephone company, a messaging service associated witha native operating system associated with the sender's client device, oran instant messaging service associated with a cross-platform messagingservice. Note that while the process 400 is described for a particularsender sending money to the recipient 402, in other embodiments, theprocess 400 can be executed for multiple senders (e.g., sender 401 1-N,where N is an integer greater than 1), where each sender can send moneyto the recipient 402 through the set of operations involved in theprocess $00. In such embodiments, the individual payment amounts fromthe multiple senders 401 1-N can be aggregated into an accumulatedpayment amount that gets transferred, by the PSS 110, to the recipient402.

In operation, the messaging application 404 (along with the messagingapplication system 405) works in coordination with an API associatedwith the payment service system 110 to monitor the communicationmessages created via the messaging application 404. The communicationmessages can be, for example, text messages, user-to-user chat messages,or group chat(room) messages. In particular, the messaging application404 monitors these communication messages to detect an indication of anintent to transfer money from a particular user (e.g., the sender 401)to a particular recipient (e.g., the recipient 402). The messagingapplication 404 detects the indication of the intent based on anidentification of a syntax, or more specifically, an input, within anyof the communication messages, that has a particular syntax. In someembodiments, the detection can be based on a parsing of the messages toidentify the syntax. As discussed above, the syntax includes a monetaryindicator preceding one or more alphanumeric characters. The inputhaving the syntax is representative of a payment proxy to which thesender 401 wishes to send money.

In the embodiments illustrated in FIG. 4, the process 400 relates to atext message 403 created by the sender 401. The message 403 includes,within a body of the message 403, the input “Awesome street performance!Here's $5 support from me.” Further, the sender 401 inputs, into a TOfield of the message 403, a string of characters to indicate to whom thesender 401 wishes to send the message 403. Note that the sender 401 maynot have any personal relationship with the recipient 402, and as such,may not know a phone number, an email address, or any other personalcontact information of the recipient 402. However, the sender 401 cansend money to the recipient 402 by simply specifying, in the message403, the payment proxy associated with the recipient 402. The recipient402 can “advertise” or otherwise display his payment proxy to be seen bythe sender 401, e.g., on a website (e.g., personal homepage), on acardboard sign while he is conducting a street performance, etc. Thesender 401, who wishes to send money to the recipient 402, e.g., assupport for the street performance, can use the displayed payment proxyto send money.

In some embodiments, the sender 401 can send a blank message to therecipient 402 using the payment proxy associated with the recipient 402.In such embodiments, the blank message can be configured to correspondto a default transaction amount; that is, when a message, with thepayment proxy included, is sent without any further e.g., comments inthe body of the message, the default transaction amount is transferredto the recipient. The default amount for a blank message can beconfigured by a user. For example, a sender who has set the defaultamount is $50, can contribute to the ALS organization by inputting $ALSand hit “Send.” As a result, the default $50 amount is automaticallytransferred to the ALS. In another example, the sender can utilize thepreconfigured default amount with transactions for products or servicesthat have fixed costs. For example, the sender can set the defaultamount to be $20 as she often visits a salon with typical fixed chargeof $20; the next time the sender is at the salon, she can simply input$KSalon and $20 is automatically sent without requiring any personalnote in that message (i.e., no need to specify context or amount).

In some embodiments, the body of the message could be self-populatedwith the amount based on past transactions or conversation historybetween the sender and the recipient (and/or other contacts). In suchembodiments, a notification can be generated to prompt the sender toconfirm addition of the self-populated amount. The various rules of thedefault amount can be preconfigured by the sender and/or a system admin,and stored in the database.

Note, the identity of the sender in the message received by therecipient may be displayed as anonymous in some embodiments. In someembodiments, the identity of the sender is displayed using a predefinedidentifier. The predefined identifier can be the “real” identity of thesender, e.g., the sender's actual payment proxy, actual name, actualuser account name, actual email address, and/or any other actual avatarof the sender. Alternatively, the predefined identifier can be anyidentity preselected by the sender, e.g., a temporary made-up username,a “junk” email address usually used by the sender, etc. Concealment ofthe sender's identity can be implemented using encryption to map thesender's real identity (e.g., payment proxy of the sender or any otheravatar) to a “concealed” address before passing it on to the recipientat the recipient's device.

Similarly, the recipient 402 can configure different identities to beassociated with his/her payment proxy for payment processing. Amongother benefits, such capability enables the recipient 402 to have alayer of different payment proxies to avoid giving the “real” address ofa division of finances. In particular, the recipient can receive moneyat a payment proxy A, and be able to divide, or distribute, the moneyreceived among 3-4 divisions or payment proxies unbeknownst to thesender. For example, the recipient associated with the payment proxy“$funnyguy311” can configure a rule that, for every $100 received, $50is distributed to another payment proxy e.g., $funnyguy_bandmate. Inanother example, for donations to a recipient 402 with payment proxy$ALS, the money can be distributed evenly between $research and$awareness, as soon as the payment is received from the sender 401.

Upon an indication to send (e.g., user interaction with the actionbutton “Send” displayed within a GUI of the messaging application 404),the messaging application system 405 receives the message 403 from themessaging application 404, and identifies that the message 403 includesan input that has the syntax. In particular, the messaging applicationsystem 405 parses the TO field of the message 403 to identify the inputhaving the syntax. For example, the input having the syntax is a stringof characters that includes the monetary indicator preceding multiplealphabetic characters and multiple numeric characters (e.g.,“$funnyguy311”). The input having the syntax is representative of apayment proxy.

Identification of the payment proxy in the TO field of the message 403triggers the messaging application system 405 to forward the message 403to the PSS 110 (e.g., via API 116 of FIG. 1), as indicated by block 410.In particular, the messaging application system 405 sends a notificationmessage to the PSS 110 that includes the message 403 and other dataassociated with the message 403 and/or the sender 401 who hascreated/sent the message 403. The other data, or information, caninclude, for example, a sender identifier associated with the sender401. Such an identifier can include, for example, a phone number of thesender 401 (e.g., the phone number of the sender device used to send themessage 403 (e.g., a text message)), and/or an email address of thesender 401 (e.g., the email address registered with the sender deviceused to send the message 403). In some embodiments, the senderidentifier can be derived from a user account registered with themessaging application system 405 (e.g., a chat ID, a cellular account,etc.).

In some embodiments, upon receiving the notification message thatincludes the sender identifier, the PSS 110 communicates with themessaging application system 405, as indicated by block 412, to cause aconfirmation message 406 to be displayed at the sender device of thesender 401, by using the sender identifier. The confirmation message 406includes a confirmation link in the form, e.g., of an action button, toenable the sender 401 to confirm the money transfer. Upon receiving aconfirmation from the sender 401 (e.g., via the messaging application404 and the messaging application system 405), the PSS 110 proceeds toblocks 416A and/or 416B. In some embodiments, the PSS 110 proceeds toblocks 316A and/or 316B without sending the confirmation message 406. Insuch embodiments, the PSS 110 proceeds to blocks 416A and/or 416Bwithout having to receive the confirmation back from the sender 402.

In some embodiments, upon receiving the notification from the messagingapplication system 405, the PSS 110 parses the message 403, and morespecifically, the TO field of the message 403 to identify the paymentproxy (and the recipient to whom money is to be transferred), asindicated by block 414. Note that, in such embodiments, the messagingapplication 404 and/or the messaging application system 405 may parsethe TO field only partially, and upon identifying the syntax, forwardssome or all of the information about the message 403 to the PSS 110 forfurther analysis (e.g., further parsing of the TO field). By parsing theTO field associated with the message 403, the PSS 110 can identify arecipient financial account based on the identified payment proxy. Insome embodiments, the PSS 110 identifies the recipient financial accountby accessing the DB 114 of FIG. 1, which maintains data relating to useraccounts and associated financial accounts in one or more databasetables. In such embodiments, the PSS 110 utilizes the parsed textassociated with the payment proxy (e.g., the alphanumeric characters of“funnyguy311”) to find a mapping of a financial account with the parsedtext. In particular, the PSS 110 can perform a database lookup todetermine who is the recipient associated with the payment proxy (e.g.,Is there a user of the PSS 110 that is associated with the payment proxy$funnyguy311?).

For example, the PSS 110 searches one or more database tables of the DB116 corresponding to, e.g., funnyguy311 or $funnyguy311. An example ofthe database tables are shown in FIG. 9 (e.g., database tables 902, 904,and 906). Within the database tables of the DB 116, the recipient useraccount can be represented by an identifier associated with therecipient. The identifier can include, for example, an email address, atelephone number, an application ID, a device ID, or biometric data(e.g., fingerprint, iris, voice, facial features, etc.) In someembodiments, the recipient user account is the payment proxy.

Upon identifying the recipient user account, the PSS 110 identifies therecipient financial account associated with that user account. In someembodiments where the recipient user account is the payment proxy, thePSS 110 simply identifies the recipient financial account without firstidentifying the recipient user account registered with the PSS 110. Toidentify the recipient financial account, the PSS 110 can determine thefinancial account information that identifies that recipient financialaccount. The financial account information can include, for example,card number, expiration date, CW, billing address, etc.

If the PSS 110 is able to identify the recipient financial account, thePSS 110 can proceed to identify the sender financial account, if notidentified already. Once both financial accounts are identified, the PSS110 can cause a payment amount to be transferred from the financialaccount associated with the sender 301 to the financial accountassociated with the recipient 402, as indicated by block 416A.

If the PSS 110 is unable to identify the recipient financial account,the PSS 110 can send a message to request financial account informationfrom the recipient 402 (e.g., a confirmation message that includes afinancial account request message), as indicated by block 416B. Themessage can be sent to the recipient 402 by using an identifier of therecipient (“recipient identifier”) that is stored in association withthe recipient user account (and/or in association with the paymentproxy). The recipient identifier can include, for example, an emailaddress or a telephone number of the sender, the recipient, or arepresentative of the recipient or sender. For example, the PSS 110sends an email message to an email address of the recipient 402, wherethe email message includes a hyperlink that redirects the recipient 402to, e.g., a webpage that allows submission of financial accountinformation, such as the debit card information associated with a debitcard, such as a debit card 408. An example of such an email message isshown in FIG. 10B. In another example, the PSS 110 sends a text messageto a telephone number of the recipient 402, where the text messageincludes a hyperlink similar to the one included in the example emailmessage. An example of a webpage for submitting financial accountinformation is shown as the user interface 1102 in FIG. 11.Alternatively, the sender 401 can submit the financial information ofthe recipient 402 that the sender 401 has acquired from the recipient atsome point. For example, the sender 401 may have had a verbal exchangeof financial information with the recipient 402. The recipient 402 mayhave verbally provided, for example, a routing number or account numberin that verbal exchange. In another example, the sender 401 may have a(paper or electronic) copy of a check (e.g., void check or check to payfor another transaction) from the recipient 402. The sender 401 canacquire, for example, the routing number and/or an account number fromthat check.

The PSS 110, upon notification (i.e., block 410), also determines who isthe sender 401, and more specifically a financial account of the sender401 (“sender financial account”) to process the money transfer, asindicated by block 414. The PSS 110 can identify the sender 402 by usingthe other information, such as the sender identifier, included in thenotification message from the messaging application system 405. Inparticular, the PSS 110 accesses the database 114, which maintains dataon user accounts and associated financial accounts in one or moredatabase tables, to identify whether, e.g., the email address of thesender 401, exists in the database 114. Upon finding the senderidentifier, the PSS 110 determines the sender financial account. Notethat the sender 401 may not already have an account with the PSS 110,but would still be able to transfer money to the recipient by use of thepayment proxy. In such scenario where the sender 401 is not yet known tothe PSS 110, the PSS 110 sends a message (e.g., a confirmation messageof the sender 401's intent to transfer money) to request for financialaccount information of a financial account, e.g., as indicated by block416B. The sender financial account can be associated, for example, witha payment card, such as a debit card 408, or credit card. In someembodiments, the confirmation message can be sent at block 412 asdiscussed above.

In addition to identifying the sender financial account and therecipient financial account, the PSS 110 also determines a paymentamount that the sender 401 desires to send to the recipient 402. The PSS110 can determine the amount by analyzing the message 203 to identify asecond input that has the syntax of the monetary indicator preceding oneor more alphanumeric characters. In particular, the PSS 110 parses themessage 403 to identify the second input representative of the paymentamount. The second input can be a string of characters that includes themonetary indicator and one or more numeric characters. For example, theamount can be identified based on the input, “$5,” included in themessage 403. In some embodiments, the PSS 110 can determine the amountby analyzing the message 403 to identify an input that includes one ormore numeric characters, without the input having the syntax. Forexample, the PSS 110 parses the message 403 to identify the amount basedon an identification of the input “5.” In some embodiments, the amountcan be parsed from the message 403 based on natural language processingand/or context of the message 403.

Once both the sender financial account and the recipient financialaccount are identified (or received by the PSS 110 via the confirmationmessage), the PSS 110 proceeds with block 416A to initiate a transfer ofmoney. Initiating the money transfer can include, for example, the PSS110 communicating a request to a card issuer of the sender 401 totransfer the money. In another example, the PSS 110 processes a card ofsender 401, e.g., a credit card or a debit card, holds the paymentamount on behalf of the recipient 402, and can forward the paymentamount to the recipient 402 once a financial account has been linkedwith the PSS 110. Alternatively, the PSS 110 can generate a transactionusing ACH that debits an amount from a bank account of the sender 401and can credit the amount into a bank account of recipient 402, e.g.,using ACH, or onto a debit account, e.g., over debit rails, of therecipient 402.

In some embodiments, the PSS 110 sends a confirmation message to a user(e.g., a sender) to obtain a confirmation, even if the financial accountof the user has already been identified, before the PSS 110 sends therequest to transfer money, e.g., the card network or the ACH network. Insuch embodiments, the confirmation message operates as a safety measureto ensure that it is the user that wishes to participate in the moneytransfer. This can be beneficial, for example, for the sender 401 whomay have inadvertently triggered the money transfer, may have enteredthe incorrect payment proxy (e.g., $funnyguy311 versus $funnyFunGuy),and/or may have changed his/her mind and wishes to cancel the moneytransfer. On the other hand, the recipient 402 may also benefit fromreceiving a confirmation message, for example, to verify who has sentmoney and/or to decline the money from the sender 401.

FIG. 5 illustrates a data flow diagram of an overview of a moneytransfer process 500 between a sender 501 and a recipient 502, by use ofa payment proxy within a forum context, in accordance with someembodiments of the disclosed technology. The process 500 involvescommunication between a computer system 505 of a forum 504 (“forumsystem 505”) and the PSS 110. The forum system 505 can be, or include,the Web server 104 of FIG. 1, that is employed by a content provider.The content provider can include social networking, blogging, ormicroblogging services. In some embodiments, the forum may also refer toan application or webpage of an e-commerce or retail organization thatoffers products and/or services. Such websites can provide an online“form” to complete before or after the products or services are added toa virtual shopping cart. The online form may include one or more fieldsto receive user interaction and engagement. Some of these fields may beconfigured to receive payment information, such as a payment proxy, inlieu of payment card mechanisms, such as credit cards, debit cards,prepaid cards, gift cards, virtual wallets, etc.

Note that while the process 500 is described for a particular sendersending money to the recipient 502, in other embodiments, the process500 can be executed for multiple senders (e.g., sender 501 1-N, where Nis an integer greater than N), where each sender can send money to therecipient 502 via the set of operations involved in the process 500. Insuch embodiments, the individual payment amounts from the multiplesenders can be aggregated into an accumulated payment amount that getstransferred, by the PSS 110, to the recipient 502.

The process 500 starts with the sender 501 accessing the forum 504, orwebsite, executed or hosted by the forum system 505, as indicated byblock 520. The website can be, for example, a social networking website,a microblog, a blog, or any other media channels that enablecommunication between users of the website. In some embodiments, theforum system 505 authenticates the sender 501 before allowing access.Authentication can involve, for example, verifying login credentialssubmitted by the sender 501, e.g., by using a sender device of thesender 501, such as the client device 102B, to the forum system 505. Thelogin credentials can be a username and password that correspond to auser account registered with the forum system 505. In some embodiments,the username can be an email address or a phone number of the sender501, where such username can operate as a sender identifier of thesender 501. In some embodiments, the sender identifier is submitted inaddition to a username and is stored by the forum system 505 inassociation with the username for the newly created user accountregistered with the forum 504.

In operation, the forum system 505 works in coordination with an APIassociated with the PSS 110 to monitor the content made or created bythe users of the forum 504. The content can include, for example, usermessages, posts, comments, user interactions, etc. (hereinafter, “usermessages,” for ease of discussion of the process 500). In particular,the forum system 505 monitors the user messages to detect an indicationof an intent to transfer money from a particular user (e.g., the sender501) to a particular recipient (e.g., the recipient 502). The forumsystem 505 detects the indication of the intent based on anidentification of a syntax, or more specifically, an input, within anyone of the user messages, that has a particular syntax. In someembodiments, the detection can be based on a parsing of the usermessages to identify the syntax. In some embodiments, any syntax in aform field dedicated for a payment proxy can be identified as intent. Asdiscussed above, the syntax includes a monetary indicator preceding oneor more alphanumeric characters. The input having the syntax isrepresentative of a payment proxy at which the sender 501 wishes to sendmoney. The input can be a string of characters that include the monetaryindicator and one or more alphabetic characters. For example, the inputis $redcross. In another example, the input is $aaron. The input can bea string of characters that include the monetary indicator and one ormore alphabetic characters and numeric characters. For example, theinput is $redcross123. In another example, the input is $aaron315.

The sender 501, for example, accesses a social networking website andposts a message 503, “I support $redcross with $25,” on the socialnetworking website (e.g., a social profile page of the sender 501 oranother user). The Web server 104 can identify the sender user's intentto transfer money to the recipient user 502 based on an identificationof the payment proxy “$redcross” included in the posted message 503.Note that the sender 501 may not have any personal relationship with therecipient 502, and as such, may not know a phone number, an emailaddress, or any other personal contact information of the recipient 502.However, the sender 501 can send money to the recipient 502 by simplyspecifying, in the message 503, the payment proxy associated with therecipient 502. The recipient 502 can “advertise” or otherwise display apayment proxy of the recipient 502 to be seen by the sender 501, e.g.,on a website (e.g., personal homepage), on a billboard, on a pamphlet,on a flyer, etc. The sender 501, who wishes to send money to therecipient 502, e.g., as support for the recipient 502, can use thedisplayed payment proxy to send money.

Referring back to the process 500, upon identification of any messagethat includes an input having the syntax, the forum system 505 sends anotification message (e.g., an API request) to the PSS 110, as indicatedby block 522. The notification message can include the identified usermessage and any other data associated with the user message and/or theuser who has created that user message (e.g., the sender 501). The otherdata, or information, can include, for example, a sender identifierassociated with the user. Such identifier can include, for example, anemail address of the sender 501 or a phone number of the sender 501. Asdiscussed above, the sender identifier can be derived from a useraccount registered with the forum system 505.

Upon receiving the notification, the PSS 110 parses the user message toidentify the input having the syntax (i.e., the payment proxy), and morespecifically, to identify who is the recipient of the money transfer, asindicated by block 524. Based on the payment proxy, the PSS 110 canidentify a recipient financial account. In some embodiments, the PSS 110identifies the recipient financial account by accessing a database,e.g., the DB 116, which maintains data 506 relating to user accounts andassociated financial accounts in one or more database tables. In suchembodiments, the PSS 110 performs a database lookup to determine who isthe recipient associated with the payment proxy (e.g., Is there a userof the PSS 110 that is associated with the payment proxy $redcross?).For example, the PSS 110 searches one or more database tables of the DB116 for, e.g., $redcross. An example of the database tables storing thedata 506 is shown in FIG. 9 (e.g., database tables 902, 904, and 906).Within the database tables of the DB 116, the recipient user account canbe represented by an identifier associated with the recipient. Theidentifier can include, for example, an email address, a telephonenumber, an application ID, a device ID, or biometric data (e.g.,fingerprint, iris, voice, facial features, etc.) In some embodiments,the recipient user account is the payment proxy.

Upon identifying the recipient user account, the PSS 110 identifies therecipient financial account associated with that user account andproceeds to process the transaction, as indicated by block 526A. In someembodiments where the recipient user account is the payment proxy, thePSS 110 simply identifies the recipient financial account without firstidentifying the recipient user account registered with the PSS 110. Toidentify the recipient financial account, the PSS 110 can determine thefinancial account information that identifies that recipient financialaccount. The financial account information can include, for example,card number, expiration date, CW, billing address, routing number, etc.The recipient financial account can be associated with, for example, adebit payment card 530.

If the PSS 110 is unable to identify the recipient financial account,the PSS 110 can send a message to request financial account informationfrom the recipient 502 (e.g., a confirmation message that includes afinancial account request message), who can provide financial accountinformation (e.g., debit card information), as indicated by block 526B.The message can be sent to the recipient by using an identifier of therecipient (“recipient identifier”) that is stored in association withthe recipient user account (and/or in association with the paymentproxy). The recipient identifier can include, for example, an emailaddress or a telephone number. For example, the PSS 110 sends an emailmessage to an email address of the recipient 502, where the emailmessage includes a hyperlink that redirects the recipient 502 to, e.g.,a webpage that allows submission of debit card information associatedwith the debit card 530. An example of such an email message is shown inFIG. 10B. In another example, the PSS 110 sends a text message to atelephone number of the recipient 502, where the text message includes ahyperlink similar to the one included in the example email message. Anexample of a webpage for submitting financial account information isshown in FIG. 11.

The PSS 110, upon notification, also determines who is the sender 501(as indicated by block 324), and more specifically a financial accountof the sender 501 (“sender financial account”) to process the moneytransfer. The PSS 110 can identify the sender 502 by using the otherinformation, such as the sender identifier, included in the notificationmessage from the forum system 505. In particular, the PSS 110 accessesthe database 116, which maintains data 506 about user accounts andassociated financial accounts in one or more database tables, toidentify whether, e.g., the email address of the sender 501, exists inthe database 116. Upon finding the sender identifier, the PSS 110determines the sender financial account. Note that the sender 501 maynot already have an account with the PSS 110, but would still be able totransfer money to the recipient 502 by use of the payment proxy. In suchscenario where the sender 501 is not yet known to the PSS 110, the PSS110 sends a message (e.g., a confirmation message of the intent of thesender 501 to transfer money) to request for financial accountinformation, as indicated by block 526B. The financial accountinformation identifies a sender financial account, which can beassociated, for example, with a payment card, such as the debit card530.

In addition to identifying the sender financial account and therecipient financial account, the PSS 110 also determines a paymentamount that the sender 501 desires to send to the recipient 502. The PSS110 can determine the amount by analyzing the message 503 to identify asecond input that has the syntax of the monetary indicator preceding oneor more alphanumeric characters. In particular, the PSS 110 parses themessage 503 to identify the second input representative of the paymentamount. The second input can be a string of characters that includes themonetary indicator and one or more numeric characters. For example, theamount can be identified based on the input, “$25,” included in themessage 503. In some embodiments, the PSS 110 can determine the amountby analyzing the message 503 to identify an input that includes one ormore numeric characters, without the input having the syntax. Forexample, the PSS 110 parses the message 503 to identify the amount basedon an identification of the input “25.” In some embodiments, the amountcan be parsed from the message 503 based on natural language processingand/or context of the message 503.

Once both the sender financial account and the recipient financialaccount are identified (or submitted to the PSS 110 via the confirmationmessage), the PSS 110 proceeds at block 526A to initiate a transfer ofmoney. Initiating the money transfer can include, for example, the PSS110 communicating a request to a card issuer of the sender 501 totransfer the money. In another example, the PSS 110 processes a card ofsender 501 e.g., a credit card or a debit card, holds the payment amounton behalf of the recipient 502, and can forward the payment amount tothe recipient 502 once a financial account has been linked with the PSS110. Alternatively, the PSS 110 can generate a transaction using ACHthat debits an amount from a bank account of the sender 501 and cancredit the amount into a bank account of the recipient 502, e.g., usingACH, or onto a debit account, e.g., over debit rails, of the recipient502.

In some embodiments, initiating the money transfer includes sending aconfirmation message to a user to obtain financial account informationfrom that user. In such embodiments, the PSS 110 may not have thefinancial account information of both the sender 501 and the recipient502. The PSS 110 can send to the user a confirmation message thatincludes a confirmation link that redirects the user to a page (e.g., aweb page or a GUI of an application) that contains a form, e.g., a webform with fields, that the user can submit the financial accountinformation. Once the financial account information is received, the PSS110 can cause money to be transferred, e.g., by sending a request to anappropriate card issuer, or by processing a card, or by using ACH (asdiscussed above).

If the sender financial account information cannot be identified, thePSS 110 can send the confirmation message to the sender 201. Forexample, the PSS 110 sends the confirmation message to the sender 501 byusing a sender identifier, e.g., an email address received from theforum system 505. The confirmation message includes a confirmation linkthat prompts the sender 501 to confirm the intent to transfer money tothe recipient 502 (identified based on association with the paymentproxy included in the message 503). An example of such a confirmationmessage is shown in FIG. 10A. The sender 501 can confirm by engagingwith the confirmation link. For example, the confirmation link is a URLlink that redirects the sender 501 to a web form with fields thatprompts the sender 501 to submit financial account information in orderto confirm the money transfer to the recipient 502. In such an example,the sender 501 can engage with the URL link by clicking and entering thefinancial account information into the web form, e.g., via a touchscreen display, a mouse, or any other input/output device of a senderdevice of the sender 501. An example of such a web form is shown in FIG.11.

If the recipient financial account information cannot be identified, thePSS 110 can send the confirmation message to the recipient 502. Forexample, the PSS 110 sends the confirmation message the recipient 502using a recipient identifier stored in association with the paymentproxy, e.g., an email address. The confirmation message includes aconfirmation link that prompts the recipient 502 to accept the moneytransfer from the sender 501 (identified based on a sender identifierassociated with the message 503). An example of such a confirmationmessage is shown in FIG. 10B. The recipient 502 can confirm by engagingwith the confirmation link. For example, the confirmation link is a URLlink that redirects the recipient 502 to a web form with fields thatprompts the recipient 502 to submit financial account information inorder to confirm the money transfer from the sender 501. In such anexample, the recipient 502 can engage with the URL link by clicking andentering the financial account information into the web form, e.g., viaa touch screen display, a mouse, or any other input/output device of asender device of the sender 501. An example of such a web form is shownin FIG. 11.

In some embodiments, the PSS 110 sends a confirmation message to a usersimply to obtain a confirmation, even if the financial account of theuser has already been identified. In such embodiments, the confirmationmessage operates as a safety measure to ensure that it is the user thatwishes to participate in the money transfer. This can be beneficial, forexample, for the sender 501 who may have inadvertently triggered themoney transfer, may have entered the incorrect payment proxy (e.g.,$redcross versus $red4cross), and/or may have changed his/her mind andwishes to cancel the money transfer. On the other hand, the recipient502 may also benefit from receiving a confirmation message, for example,to verify who has sent money and/or to decline the money from the sender501.

FIG. 6 is a user interface diagram illustrating an example interface 600relating to a money transfer flow associated with the cash taggingtechnology, in accordance with some embodiments. The interface 600 canbe generated by a web browser application 620 that is used for accessingcontent of one or more websites via the Internet. The interface 600 candisplay content of a website (e.g., “www.communitysite.com”) that hosts,or operates as, an online communication platform for, e.g., anelectronic bulletin boards or an online social networking service. Inthe embodiment of FIG. 6, the interface 600 displays content of ahomepage of a user account of a user “Alex.” The content displayed atthe interface 600 includes a first message 602 electronically posted, orwritten, by a user “Betty.” The message 602 includes, among others, afirst input 604 and a second input 606, where each of the first andsecond inputs 604, 606 contains a specified syntax of a monetarycurrency indicator (e.g., “$”) prefixing one or more alphanumericalcharacters. In particular, the first input 604 includes the monetarycurrency indicator prefixing a set, or string, of alphabetic characters(i.e., “alex”), and the second input 606 includes the monetary currencyindicator prefixing a numeric character (i.e., “5”).

The web browser application 620, upon detecting the first input 602 andthe second input 604 having the specified syntax, communicates (eitherdirectly or indirectly) with a PSS (e.g., the PSS 110 of FIG. 1) toinitiate a transfer of funds. In response to a communication from theweb browser application 620, the PSS can process the transfer of fundsby determining who is the sender of the funds, who is the recipient ofthe funds, and what is the amount to be transferred. The PSS canidentify the amount based on the second input 606. In particular, thePSS can parse the second input 606 to determine the amount from the oneor more numerical characters included in the second input 606.

In some embodiments, the PSS can identify the sender and the recipient,respectively, based on identification information received via the webbrowser application 620. In such embodiments, the web browserapplication 620 can communicate with a server computer system (notshown) that hosts the website content displayed in the interface 600.The server computer system can respond by transmitting user profileinformation associated with the user (e.g., “Betty” or “Alex”) to thePSS, where the user profile information is part of account informationmaintained by the server computer system. The user profile informationcan include the identification information, which can be, for example,an email address, a telephone number, a username. In some embodiments,the PSS can utilize that information to reach out to the user (e.g.,“Betty” or “Alex”) for payment card information to process the requestto transfer funds. The PSS, for example, can generate a message thatincludes a hyperlink to redirect the user to a landing page to submitpayment card information (e.g., interfaces 500 and 502 of FIG. 5). Insome embodiments, the PSS can identify the recipient based on the firstinput 604 (i.e., “$alex”). In such embodiments, the PSS can perform adatabase search to determine if the first input 604 matches with a useraccount associated with the PSS.

Upon a successful processing of the request to transfer funds, the PSScan notify the recipient. For example, the recipient can receive anemail message from the PSS. In another example, the PSS can cause amessage to be displayed at a home page of a user account associated withthe web browser application 620 (e.g., homepage of the user “Betty” orthe user “Alex”). The content of the interface 600 includes a secondmessage 608 posted by the user, or recipient, “Alex.” The second message608 can be an example of a message the recipient can post to notify thesender that the five dollars has been successfully deposited into hisfinancial account.

Note that while the message 602 indicates the user Betty wishes to sendmoney to a recipient according to the embodiment of FIG. 6, in otherembodiments, the user Betty, for example, can post a similar message torequest (as opposed to send) money from another user, e.g., user Alex.In such embodiments, the user Betty can post, for example, a messagestating “$alex, pls send me $5 for the smoothie run. Thanks!” In thisexample, the PSS can process the money transfer request from Betty uponreceiving notification of the detection of the first input of “$alex”and the second input of “$5” included in the message.

FIG. 7 illustrates a data flow diagram of an overview of a moneytransfer process 700, between a sender 701 and a recipient 702, by useof a payment proxy within a landing page, in accordance with someembodiments of the disclosed technology. The process 700 involvescommunication between a landing page 704 that is associated with the PSS110 and the PSS 110 of FIG. 1. The landing page 704 can be executed bythe one or more servers 112 (e.g., a web server) of the payments servicesystem 110. The landing page 704 can be generated by the PSS 110 toreceive, or collect, one or more payments on behalf of the recipient 702from one or more senders (e.g., 701A, 701B, 701C, etc.). As illustratedin FIG. 7, the landing page 704 is embodied as a website whose URL canbe personalized based on a payment proxy associated with the recipient702. In particular, the landing page 704 can be generated bycanonicalizing the URL to a unique representation that includes at leasta portion of the payment proxy to personalize the landing page 704 forthe recipient 702. For example, a personalized landing page can have aURL that includes, for example, a monetary indicator preceding multiplealphabetic characters (e.g., www . . . com/$redcross). In someembodiments, the URL can be different from the payment proxy, yet stillbe canonicalized for ease of use in transferring money to the recipient702 via the landing page 704.

The sender 701 can visit the landing page 704 to send money to therecipient 702. Note that while the process 700 is described for aparticular sender 701 sending money to the recipient 702, in otherembodiments, the process 700 can be executed for multiple senders (e.g.,701A, 701B, 701C), where each sender can send money to the recipient 702by visiting the landing page 704 and submitting individual paymentamounts. In such embodiments, the individual payment amounts from themultiple senders can be aggregated into an accumulated payment amountthat gets transferred, by the PSS 110, to the recipient 702.

The process 700 starts with the sender 701 accessing the landing page704, e.g., by entering a URL into a web browsing application installedon a sender device of the sender 701 (e.g., the client device 102C ofFIG. 1). In some embodiments, the sender 701 can access the landing page704 by navigating from another webpage associated with the PSS 110(e.g., a user profile page). In such embodiments, the sender 701 haslogged into, e.g., the user profile page, which enables the PSS 110 toknow the identity of the sender 701. The identity information caninclude, for example, a sender identifier, such as an email address, ofthe sender 701. The PSS 110 can utilized the sender identifier inexecuting some operations of the process 700, as will be discussedfurther below.

Upon arriving at the landing page 704, the sender 701 can simply enter apayment amount, e.g., in an input field displayed at the landing page704, and send the money, e.g., by engaging with a “PAY!” action buttondisplayed at the landing page 704. The landing page 704, in response,sends the user request (i.e., request to pay the recipient 702) to thePSS 110, e.g., via the API 114. In some embodiments, the PSS 110responds with data for displaying a message 706 to the sender 701 at thelanding page 704. In some embodiments, the message 706 prompts thesender 701 to enter a unique identifier associated with the sender 701to confirm the money transfer to the recipient 702.

Upon receiving the unique identifier, the landing page 704 forwards theidentifier to the PSS 110, which utilizes the identifier to determine afinancial account associated with the identifier (“sender financialaccount”). In some embodiments, the PSS 110 determines the senderfinancial account based on a stored association between the senderfinancial account and the identifier, where that sender financialaccount has been registered with the PSS 110 in a previous transaction.

In some embodiments, the PSS 110 proceeds to identify the senderfinancial account without prompting (e.g., via the message 706) theidentifier from the sender 701. In such embodiments, the PSS 110 canidentify the identifier based on the navigation of the sender 701 to thelanding page 704 from a page associated with the PSS 110 (e.g., a userprofile page at another website or a payment service application). Thatis, based on the login credentials submitted at the page associated withthe PSS 110, the PSS 110 is able to retrieve the identifier associatedwith the sender 701 to determine the sender financial account, withoutneed for prompting the identifier from the sender 701.

Note that the sender 701 may not already have an account with the PSS110, but would still be able to transfer money to the recipient 702 bynavigating to the landing page 704 associated with the recipient 702. Insuch scenario where the sender 701 is not yet known to the PSS 110, thePSS 110 can determine the sender 701 based on the sender identifier. Forexample, the PSS 110 obtains the identifier via the confirmation message706, as discussed with respect to block 712. In another example, the PSS110 obtains the sender identifier based on login credentials associatedwith the payment service application provided by the PSS 110.

In some embodiments, the PSS 110 also determines a financial accountassociated with the recipient (“recipient financial account”). In someembodiments, the PSS 110 identifies the recipient financial accountbased on an association of the recipient financial account with thepayment proxy included in the URL of the landing page 704. In someembodiments, the PSS 110 identifies the recipient financial accountbased on an association of the recipient financial account with thelanding page 704.

In addition to identifying the sender financial account and therecipient financial account, the PSS 110 also determines a paymentamount that the sender 701 desires to send to the recipient 702. The PSS110 can determine the amount by analyzing the input that the sender 701enters at the landing page 704. In some embodiments, the PSS 110determines one or more financial accounts associated with additionalsenders (e.g., 701B and 701C) that submit a payment amount at thelanding page 704 for the recipient 702. In such embodiments, the PSS 110aggregates the individual payment amounts to generate an aggregatedpayment amount. In some embodiments, as briefly discussed above, theaggregated payment amount may be distributed to multiple financialaccounts associated with the payment proxy. For example, the totalamount received from donations from five family members can bedistributed to a summer camp fund (e.g., $summerSmithKids) and aback-to-school supplies fund (e.g., $b2school).

At block 714A, the PSS 110, having identified the sender financialaccount, the recipient financial account, and the payment amount (oraggregated payment amount), initiates a transfer of the payment amountfrom the sender financial account to the recipient financial account.Initiating the money transfer can include, for example, the PSS 110communicating a request to a card issuer of the user sender 701 (or eachcard issuer of the senders 701A, 701B, 701C) to transfer the money. Inanother example, the PSS 110 processes a card of sender 701, e.g., acredit card or a debit card, holds the payment amount on behalf of therecipient 702, and can forward the payment amount to the recipient 702once a financial account has been linked with the PSS 110. Note this setof operations can be performed for each card associated with each of thesenders (e.g., 701A, 701B, 701C). Alternatively, the PSS 110 cangenerate a transaction using ACH that debits an amount from a bankaccount of the sender 701 and can credit the amount into a bank accountof the recipient 702, e.g., using ACH, or onto a debit account, e.g.,over debit rails, of the recipient 702. Note this set of operations canalso be done for each bank account of each senders (e.g., 701A, 701B,701C).

In some embodiments, the PSS 110 sends a confirmation message to a userto obtain a confirmation before causing the money to be transferred,even if the financial account of the user has already been identified.In such embodiments, the confirmation message operates as a safetymeasure to ensure that it is the user that wishes to participate in themoney transfer. This can be beneficial, for example, for the sender 701who may have inadvertently triggered the money transfer, may haveentered the incorrect payment proxy (e.g., $redcross versus $red4cross),and/or may have changed his/her mind and wishes to cancel the moneytransfer. On the other hand, the recipient 702 may also benefit fromreceiving a confirmation message, for example, to verify who has sentmoney and/or to decline the money from the sender 701.

FIG. 8 is a block diagram illustrating various components of a paymentservice system 800 (“PSS 800”) executing the cash tagging technology, inaccordance with some embodiments. In some embodiments, the PSS 800 canbe the PSS 110 of FIG. 1. The PSS 800 includes a network interface 802,a money transfer request processor 804, and a notification engine 806(“request engine 806”). In some embodiments, the PSS 800 furtherincludes one or more databases, such as a user account database 820 (“DB820”), a payment card database 822 (“DB 822”), and a transaction historydatabase 824 (“DB 824”).

The network interface 802 can be a networking module that enables thePSS 800 to transmit and/or receive data in a network with an entity thatis external to the PSS 800 (e.g., a remote server associated with acommunication application), through any known and/or convenientcommunications protocol supported by the PSS 800 and the externalentity. The network interface 802 can include one or more of a networkadaptor card, a wireless network interface card (e.g., SMS interface,WiFi interface, interfaces for various generations of mobilecommunication standards including, but not limited to, 1G, 2G, 3G, 3.5G,4G, LTE, etc.), Bluetooth, a router, an access point, a wireless router,a switch, a multilayer switch, a protocol converter, a gateway, abridge, bridge router, a hub, a digital media receiver, and/or arepeater.

Each of the DBs 820, 822, and 824 can include, for example, one or morehard drives (which may be further coupled together using RAID-0, 1, 5,10, etc.), a centralized or distributed data cluster, a cloud-storageservice provider, or other suitable storage systems suitable for storingdigital data. The DB 822 can store various fields of data, such as useridentifiers (IDs) (e.g., email addresses, telephone numbers, usernames,unique IDs associated with the cash tagging technology (“unique cashID”) (e.g., $alex), device IDs, etc.), user profile information,shipping address, billing address, and/or the like. The DB 822 can storevarious fields of data, such as user identifiers associated with paymentcards, payment card/account numbers, expiration dates, card/accounttype, CWs, billing addresses, and/or the like. The DB 824 can storevarious fields of data, such as transaction identifiers (IDs), useridentifiers (IDs), transaction dates/times, amounts, transactionparticipant identification information (e.g., email addresses ortelephone numbers associated with the senders and recipients of moneytransfer transactions), and/or the like.

The PSS 800 can access the databases 820, 822, and 824 to retrieveand/or store data for executing the cash tagging technology. Inparticular, the PSS 800 can search the databases 820, 822, 824 for datastored in association with other relevant data needed to process moneytransfers associated with the cash tagging technology. For example, thePSS 800 can store, in any of the databases 820, 822, and/or 824, a newlycreated unique cash ID of a user (e.g., sender user or recipient user)in association with another identifier associated with the user (e.g.,telephone number, email address, instant message username, etc.). Inthis example, the PSS 800 can create the unique cash ID in response to,for example, the user registering for a money transfer service via thetagging mechanism, which is provided by the PSS 800. The registrationcan include, for example, the user submitting payment card informationfor the PSS 800 to process the money transfer service. In anotherexample, the PSS 800 can search and retrieve, from the databases 820,822, and/or 824, a user's email address that is stored in associationwith the user's unique cash ID. In some embodiments, the data stored inthe DBs 820, 822, and 824 can be utilized for determining intent of asender to transfer money. For example, data about past transactions canhelp the PSS 800 determine the context of a message composed by asender, and utilize such context to predict the intent to transfermoney.

The money transfer request processor 804 (“processor 804”) can processmoney transfer requests associated with the cash tagging technology asdescribed in detail throughout the specification, for example, at leastwith respect to FIGS. 1-5. For example, the processor 804 can receive amoney transfer request from a communication application (and/or a servercomputer system associated with the communication application), parsethe money transfer request to extract details such as identificationinformation that identifies a money sender (e.g., telephone number),identification information that identifies a money recipient (e.g., aunique cash ID), the amount, and the like. The processor 804 can check,based on the identification information associated with the money senderand the money recipient, respectively, whether the respectiveidentification information are associated with one or more payment cardsof the money sender and recipient, respectively. For example, theprocessor 804 accesses the DBs 820, 822, and/or 824 to determine whetherthe money sender's telephone number is associated with payment card datathat identifies the money sender's payment card. In another example, theprocessor 804 accesses the DBs 820, 822, and/or 824 to determine whetherthe unique cash ID of the money recipient is associated with paymentcard data that identifies the money recipient's payment card. Theprocessor 804 can then initiate a transfer of an amount associated withthe money transfer request from, e.g., a bank account funding the moneysender's payment card to a bank account associated with the moneyrecipient's payment card.

In some embodiments, users (e.g., the money sender and the moneyrecipient) can have mobile applications installed on their mobiledevices. In such embodiments, the money transfer requests associatedwith those users can cause the notification engine 806 to generate andsend push notifications using a push notification module 806. In someembodiments, a push notification for a money transfer request may begenerated based on information included in the money transfer request,and can prompt the user to confirm or cancel the money transfer request.For example, a push notification can be a message that prompts a senderuser to confirm she wants to send money to a recipient (i.e., confirmher intent to send money when she has submitted an input with aspecified syntax). In some embodiments, the push notification can promptthe user to provide payment card information associated with a paymentcard of the user to process the money transfer request. Based on theuser's response, the PSS 800 can process the money transfer request byinitiating transfer of an amount of funds corresponding to the moneytransfer request.

In some embodiments, the notification engine 806 can include an emailnotification module 810 to generate and send email notifications. Insuch embodiments, the notification engine 806 is able to communicatewith users who may not have the mobile application installed on theirmobile devices and/or may not have mobile devices. An email notificationgenerated by the email notification module 810 can be in the form of anelectronic mail, or email message, that prompts a user to confirm orcancel a money transfer request. In some embodiments, the email messagecan prompt the user to provide payment card information associated witha payment card of the user to process the money transfer request.

In some embodiments, the notification engine 806 can include a textnotification module 812 to generate and send text message notifications.In such embodiments, the notification engine 806 is able to communicatewith users who may not have the mobile application installed on theirmobile devices. A text message notification generated by the textnotification module 812 can be in the form of a text message thatprompts a user (e.g., a money sender user) to confirm or cancel a moneytransfer request. In some embodiments, the text message can prompt theuser to provide payment card information associated with a payment cardof the user to process the money transfer request.

Note the notification engine 806 and its associated modules can beutilized to communicate with recipient users, in addition to senderusers. For example, the email notification module 810 can generate anemail message to obtain payment card information from a recipient user.In another example, the push notification module 808 can generate a pushnotification to obtain payment card information from the recipient user.In yet another example, the text notification module 812 can generate atext message to obtain payment card information from the recipient user.

FIG. 9 illustrates example database tables coupled to the paymentservice system 110 in accordance with some embodiments of the cash tagtechnology. In some embodiments, the PSS 110 can utilize the data storedin the databases 902, 904, and/or 906 to process payment transactions(e.g., money transfers) on behalf of customer users of the paymentservice employing the PSS 110. For example, the PSS 110 can utilize thedata in the database tables 902, 904, 906 as an index of all customerusers who have user accounts and/or payment proxies registered with thePSS 110.

As illustrated, FIG. 9 illustrates example fields of a database table902, a database table 904, and a database table 906. The database table902 can include various fields of information such as, but are notlimited to, customer ID1 (e.g., payment proxy), customer ID2 (e.g.,email address), customer ID3 (e.g., phone number), first name, lastname, billing address, and/or the like. The database table 904 caninclude various fields of information such as, but not limited to,customer ID1, card identifier (e.g., card account number), issuer,expiration date, billing address, and/or the like. In some embodiments,the customer ID1 can be replaced with other customer identifiers, orIDs, associated with the same customer, e.g., customer ID2 or customerID3. The database table 906 can include various fields of informationsuch as, but are not limited to, transaction date, transaction ID,customer ID1 (e.g., a customer such as a recipient user), cusomter2 ID1(e.g., a customer such as a sender user), a transaction amount (e.g.,money transfer payment amount), and/or the like.

FIG. 10A-10B illustrate various examples of graphical user interfacesfor emails received by recipients of money transfers, in accordance withvarious embodiments of the cash tag technology.

FIG. 10A is an illustration of an example user interface 1000 of anemail message sent from a PSS (e.g., the PSS 110 of FIG. 1). The emailmessage can be sent from a payment service email address 1002 associatedwith the PSS to a sender email address 1004. The sender email address1004 is associated with an identifier (e.g., a user account registeredwith the PSS 110). In some embodiments, the sender email address 1004 isprovided as the identifier of the sender to the PSS 110. The subject1006 can include a description of the recipient (i.e., as identified bythe payment proxy) and a sent payment amount. The description 1008 ofthe email can include a link to a resource, e.g., a customized link inthe confirmation email described above in reference to variousembodiments, for the sender to link a payment card for processing thetransfer of the payment amount.

FIG. 10B is an illustration of an example user interface 1010 of anemail message sent from a PSS (e.g., the PSS 110 of FIG. 1). The emailmessage can be sent from a payment service email address 1012 associatedwith the PSS to a recipient email address 1014. The recipient emailaddress 1014 is associated with a payment proxy (e.g., $funnyguy311)included in a message of a sender to trigger a money transfer to therecipient. The subject 1016 can include a payment amount sent from thesender. The description 1018 in a body of the email can include a linkto a resource, e.g., a customized link in the confirmation emaildescribed above in reference to various embodiments, for the recipientto redeem the payment amount.

FIG. 12 is a flowchart illustrating an example process 1200 oftransferring money (or cash payment) by use of a payment proxy,according to an embodiment of the present subject matter. The process1200 can be performed by one or more components, devices, or modulessuch as, but not limited to, the client devices 102, the Web server 104,the application server 106, the PSS 110, or other component or device.As illustrated in FIG. 12, the process 600 includes a set of operationsfrom block 1202 to block 1214.

The process 1200 starts with the operation at block 1202, which detectsa message that includes a payment proxy having a particular syntax, thesyntax being a monetary indicator preceding one or more alphanumericcharacters. Performing detection can include monitoring messages atpredetermined intervals and detecting any message having the syntax. Thepredetermined intervals can be configured by an administrator of thesystem (e.g., continuously, every 5 minutes, every hour, etc.) Themessage can be created by a user at a computer system associated with acontent provider. For example, the user posts at a social networkingwebsite a message “Great performance, $funnyguy, here is $10!”, wherethat message includes the payment proxy “$funnyguy. In another example,the user sends, within an instant messaging application, a chat message“Great performance the other day! Here is 10 dollars.”, where thatinstant message is addressed to a payment proxy “$funnyguy” (e.g., inthe TO field of the instant message). The system can perform a databaselookup to interpret the message. The database can store tables that mapan amount to known templates. For example, “dollar,” “bill,” or “bucks”is mapped to currency and numeric character associated with thatcurrency is the actual amount.

The operation at block 1204 identifies a card account associated withthe user who has specified the payment proxy, e.g., $funnyguy, in themessage. The operation at block 1204 can include accessing a database todetermine a stored association between an identifier associated with theuser and the payment proxy, where that stored association has beenestablished in another transaction conducted by the sender with aservice provider providing financial services, such as a paymenttransaction, e.g., the PSS 110.

The operation at block 1206 determines whether the card accountassociated with the user has been identified. This may happen in casethe card account is unavailable or the user declines money transferlinks between accounts. If no card account is identified, the process1200 proceeds to the process 600 of FIG. 6. If a card account isidentified for the user, the process 1200 proceeds to the operation atblock 1208. The operation at block 1208 identifies a recipientassociated with the payment proxy detected at block 1202. This can becarried out, for example, by accessing a database that stores useraccount information to identify a stored association between the paymentproxy and a user account of a recipient. The stored association can beestablished in another transaction in which the payment proxy isregistered with the PSS 110. The operation at block 1210 identifies acard account that is associated with the recipient identified at block1208 based on an association between the user account of the recipientand the card account.

The operation at block 1212 determines whether the card account has beenidentified. If no card account associated with the recipient isidentified, the process 1200 proceeds to the process 600 of FIG. 6. If acard account associated with the recipient is identified, the process1200 proceeds to block 1214, at which the money transfer is initiated.In some embodiments, the operation at block 1214 includes identifying apayment amount for the money transfer based on a parsing of the messagecreated by the user. In some embodiments, the operation at block 1214also includes generating a confirmation message. The confirmationmessage can be sent to the user and/or the recipient associated with thepayment proxy to confirm the money transfer. Upon confirmation received,the money, e.g., a payment amount, is caused to be transferred to thefinancial account associated with the recipient.

FIG. 13 is a flowchart illustrating an example process 1300 of linking acard account for a transfer of money by use of a payment proxy. Theprocess 1300 can be performed by one or more components, devices, ormodules such as, but are not limited to, the client devices 102, the Webserver 104, the application server 106, the PSS 110, or other componentor device. As illustrated in FIG. 13, the process 1300 includes a set ofoperations from block 1302 to block 1306. In some embodiments, theprocess 1300 can be implemented as part of the process 1200 of FIG. 12.In some embodiments, the process 1300 can be implemented as part of theprocess 700 of FIG. 7.

The operation at block 1302 generates a message that requests, from auser, financial account information, such as payment card informationassociated with a payment card, e.g., a debit card or a credit card. Themessage can be, for example, a financial account request message. Themessage can be generated for display to a user by the client device 102of the user based on, e.g., instructions received from the PSS 110. Insome embodiments, the message can be in the form of an email message. Insome embodiments, the message can be in the form of a text message. Insome embodiments, the message can be in the form of a push notification.

The message can include a link that is configured to request thefinancial account information from a sender of a money transfertriggered by use of the payment proxy. An example of such a message isshown in FIG. 10A. The message can include a link that is configured torequest the financial account information from a recipient of a moneytransfer triggered by use of the payment proxy. An example of such amessage is shown in FIG. 10B.

The operation at block 1304 receives the financial account information,e.g., debit card account information, from the user. The financialaccount information can be received, for example, from the client device102 of the sender (e.g., sender device) or of the recipient (e.g.,recipient device). The operation at block 1306 verifies the authenticityof the financial account information received, e.g., valid expirationdate, valid card number, valid account holder name, etc. In someembodiments, if the financial account information is not valid, theprocess 1300 requests the financial account information again from theuser. For example, a second financial account request message is sent tothe user's email address. In another example, the second financialaccount request message is sent using a different identifier of theuser, e.g., a telephone number, e.g., in case the stored email addressis incorrect. The process 1300 returns if valid financial accountinformation is submitted. In some embodiments, the financial accountinformation is stored in association with the user for future uses,e.g., for processing payment transactions, such as money transfers.

FIG. 14 is a flowchart illustrating an example process 1400 oftransferring money within a landing page context. The process 1400 canbe performed by one or more components, devices, or modules such as, butnot limited to, the client devices 102, the Web server 104, theapplication server 106, the PSS 110, or other component or device. Asillustrated in FIG. 14, the process 1400 includes a set of operationsfrom block 1402 to block 1414.

The process 1400 starts with the operation at block 1402, which receivesa payment amount inputted by a sender user at a landing page associatedwith a recipient. The operation at block 1404 identifies the sender userwho has submitted the payment amount. In some embodiments, the operationat block 1404 includes generating a message to prompt the sender user tosubmit an identifier associated with the sender user, such as an emailaddress, where the submitted identifier helps to identify the senderuser. In some embodiments, the operation at block 1404 includesanalyzing any data associated with the sender user, e.g., logincredentials from a previous navigation page that has redirected thesender user to the landing page. Using the login credentials, theidentity of the sender user can be determined. For example, a previouspage visited by the sender is identified to derive the logincredentials. The previous page can be, for example, a website associatedwith the PSS 110. In another example, the previous page can be a paymentservice application associated with the PSS 110. In yet another example,the previous page can be a microblogging website associated with the Webserver 104.

The operation at block 1406 identifies a financial account, e.g., adebit card account, that is associated with the sender based on theidentifier determined at block 1404. The financial account can bedetermined based on a stored association between the identifier and thefinancial account, where the stored association is established in aprevious transaction (e.g., account registration or a past moneytransfer). The operation at block 1408 determines if the financialaccount is identified. If no account associated with the sender isidentified, the process 1400 proceeds to the process 600 of FIG. 6. Ifan account is identified, the process 1400 proceeds to block 1410.

The operation at block 1410 identifies a financial account, e.g., adebit card account, that is associated with the recipient associatedwith the landing page. The financial account associated with therecipient can be determined based on a stored association between thelanding page and the financial account, where the stored association isestablished in a previous transaction (e.g., registration of the landingpage or a past money transfer). The operation at block 1412 determinesif the financial account associated with the recipient is identified. Ifno account associated with the recipient is identified, the process 1400proceeds to the process 600 of FIG. 6. If an account is identified, theprocess 1400 proceeds to block 1414.

The operation at block 1414 initiates a transfer of the payment amountfrom the financial account associated with the sender to the financialaccount associated with the recipient. In some embodiments, theoperation at block 1414 includes identifying a payment amount for themoney transfer based on the input received via the landing page (e.g.,the input received at block 1402). In some embodiments, the operation atblock 1414 also includes generating a confirmation message to a user,such as the sender or the recipient. Upon confirmation received, themoney is caused to be transferred to the financial account associatedwith the recipient. In some embodiments, the confirmation message issent to the sender by using the sender identifier (e.g., email address).In some embodiments, the confirmation message is sent to the recipientby using an identifier associated with the landing page (e.g., emailaddress), or an identifier associated with the payment proxy.

FIG. 15 is a flow diagram illustrating an example method 1500 ofexecuting the cash tagging technology, in accordance with someembodiments. In some embodiments, the method 1500 is carried out by acommunication application 1550 (e.g., a messaging application) workingin coordination with the PSS 1560. In some embodiments, a servercomputer system associated with the communication application 1550 canperform the method 1500 in coordination with the PSS 1560. In someembodiments, the communication application 1550 is executing on a clientdevice 102 of the sender 140. In some embodiments, the PSS 1560 can bethe PSS 110 of FIG. 1.

At block 1502, the communication application 1550 receives a messageinputted by the sender, e.g., sender 140, where the message includes oneor more user inputs. At decision block 1504, the communicationapplication 1550 determines (e.g., parsing) whether any of the userinputs in the message triggers a tagging mechanism in the form of acurrency indicator (e.g., $). Based on the detection of the currencyindicator, the application 1550 can determine the user's intent, orindication, to transfer money, and can execute, or trigger execution, ofsuch money transfer, without requiring an explicit command from the userto transfer the money. The communication application 1550 furtheridentifies whether that user input is of the type with the syntax of themonetary indicator prefixing one or more numeric characters (e.g., 1, 5,20, 100, etc.), which may be stored or used in block 1512. If themessage includes a user input that contains the currency indicatorprefixing an alphabetic or a numeric character (“Yes” branch), thecommunication application 1550 can trigger execution of the moneytransfer by transmitting a message to notify the PSS 560, as indicatedin block 1506. If there is not a user input in the message that containsthe specified syntax (i.e., currency indicator prefixing one or morealphanumeric characters), the communication application 1550 continueswith its communication functionality by transmitting, or delivering, themessage to the recipient of the message, as indicated in block 1520.

At block 1508, the PSS 560 receives the message from the communicationapplication 1550, and parses the message for identification informationof the sender 140 and the recipient 102 and the amount to be transferredin the money transfer request. At block 1512, the PSS 560 identifies themoney transfer amount and the recipient 102 based on the parsedinformation. For example, the PSS 560 identifies the amount based on thesecond user input of “$5.” In another example, the second user input maybe set to a default value. In another example, the PSS 560 identifiesthe recipient 102 based on the user input of “$alex.”

At block 1514, the PSS 560 causes a message to be sent to the sender 140to prompt for a confirmation that the sender 140 wishes to transfer themoney. For example, the PSS 560 sends a message to the communicationapplication 1550 to cause it to display a message to prompt the senderfor the confirmation, as indicated in block 1516. Block 1514 is executedto ensure, for example, the intention of the sender 140 to send moneywhen the sender 140 submits the input of “$5” in the message received bythe communication application 1550.

At decision block 1518, the communication application 1550 determineswhether the sender 140 has responded with a confirmation. If the sender140 does not confirm and/or sends a confirmation (e.g., selects “No” or“Cancel” to cancel the money transfer request), the process 1500proceeds to block 1520. At block 1520, the communication application1550 can deliver the message onward to the recipient as an ordinarymessage (i.e., no money transfer is involved). In some embodiments, whenthe sender does not confirm, the message does not get delivered. Thatis, upon determination that there is no intent from then sender totransfer money and/or a determination that the sender would like tocancel the money transfer, the message does not get sent. The process1500, in such embodiments, would end. If the sender 140 does confirm(e.g., selects “Yes” or “Send cash”), the process 1500 proceeds to block1524.

At block 1524, the PSS 560 sends a message to request acceptance of themoney transfer request from the recipient 102. The PSS 560 can use theidentification information associated with the recipient 102 that hasbeen received in the message at block 1508 to deliver the acceptancerequest message. For example, the identification information associatedwith the recipient 102 includes a telephone number, which can be used bythe PSS 560 to send a text message to obtain the acceptance from therecipient 102. In another example, the identification informationassociated with the recipient 102 includes an email address, which canbe used by the PSS 560 to send a text message to obtain the acceptancefrom the recipient 102.

In yet another example, the identification information associated withthe recipient 102 includes a unique cash ID. In this example, the PSS560 can perform a database lookup to identify information associatedwith the unique cash ID, where that information can be used to reach outto the recipient 102. For example, that information can include aninstant messaging username of the recipient. In this example, the PSS560 can use the username as a reference that gets included in a requestmessage to a server computer system associated with the communicationapplication 1550, where the request message prompts the server computersystem to generate and send the acceptance request message to therecipient 102 on behalf of the PSS 560. The acceptance request messagecan include, for example, a link that redirects to a landing pagefacilitated by the PSS 560.

At block 1524, the PSS 560 determines whether the recipient 102 hassubmitted a response to accept the money transfer amount included in thesender's money transfer request. If the PSS 560 receives an acceptance,the process 1500 proceeds to block 1526, at which the PSS 560 causesfunds to be transferred from the financial account of the sender 140 tothe financial account of the recipient 102. If the PSS 560 does notreceive an acceptance, the process 1500 ends. In some embodiments, whenthe sender does not respond and/or cancels the request, a notificationmay be transmitted back to the sender 140. That is, upon determinationthat there is no intent from the recipient to accept transfer of moneyand/or a determination that then recipient would like to cancel themoney transfer, a notification message is transmitted to the sender, andthe process 1500 would end.

In some embodiments, the recipient 142 may request for a money transferfrom the sender 140. In such embodiments, the recipient 142 may utilizethe communication application 1550 for execution of a similar process1500 that is carried out on behalf of the sender 140. For example, insuch embodiments, the recipient 142 can utilize a client device tolaunch the communication application 1550 and compose a message to thesender 140 via the application 1550. Instead of a message indicatingintent to transfer money, the message from the recipient 142 canindicate an intent to request money (e.g., “Please transfer me $20 forlunch.”). The communication application 1550 can parse the message anddetect the syntax of the input “20” to determine a (reverse) moneytransfer is requested by the recipient 142. The communicationapplication 1550 can notify the PSS 1560 (e.g., by establishingcommunication links with either a payment application and/or a messagingserver in communication with the PSS 1560). The PSS 1560 can proceed byconfirming with the recipient 142 of such intent to request money fromthe sender 140. Upon confirmation by the recipient and the sender, thePSS 1560 can initiate the transfer (e.g., cause funds to be transferredfrom a financial account of the sender to the recipient).

Regarding the processes 200, 300, 400, 500, 700, 1200, 1300, 1400, and1500, while the various steps, blocks or sub-processes are presented ina given order, alternative embodiments can perform routines havingsteps, or employ systems having steps, blocks or sub-processes, in adifferent order, and some steps, sub-processes or blocks can be deleted,moved, added, subdivided, combined, and/or modified to providealternative or sub-combinations. Each of these steps, blocks orsub-processes can be implemented in a variety of different ways. Also,while steps, sub-processes or blocks are at times shown as beingperformed in series, some steps, sub-processes or blocks can instead beperformed in parallel, or can be performed at different times as will berecognized by a person of ordinary skill in the art. Further anyspecific numbers noted herein are only examples; alternativeimplementations can employ differing values or ranges.

FIG. 16 illustrates an example of a processing system controller 1600with which some embodiments of the payment proxy technology can beutilized. In some embodiments, the processing system controller 1600 canbe the PSS 110 described in FIG. 1.

The system controller 1600 may be in communication with entitiesincluding one or more users 1625, client/terminal devices 1620 (e.g.,devices 102), user input devices 1605, peripheral devices 1610, anoptional co-processor device(s) (e.g., cryptographic processor devices)1615, and networks 1630. Users 1625 may engage with the controller 1600via terminal devices 1620 over networks 1630.

Computers may employ central processing unit (CPU) or processor(hereinafter “processor”) to process information. Processors may includeprogrammable general-purpose or special-purpose microprocessors,programmable controllers, application-specific integrated circuits(ASICs), programmable logic devices (PLDs), embedded components,combination of such devices and the like. Processors execute programcomponents in response to user and/or system-generated requests. One ormore of these components may be implemented in software, hardware orboth hardware and software. Processors pass instructions (e.g.,operational and data instructions) to enable various operations.

The controller 1600 may include clock 1665, CPU 1670, memory such asread only memory (ROM) 1685 and random access memory (RAM) 1680 andco-processor 1675 among others. These controller components may beconnected to a system bus 1660, and through the system bus 1660 to aninterface bus 1635. Further, user input devices 1605, peripheral devices1610, co-processor devices 1615, and the like, may be connected throughthe interface bus 1635 to the system bus 1660. The interface bus 1635may be connected to a number of interface adapters such as processorinterface 1640, input output interfaces (I/O) 1645, network interfaces1650, storage interfaces 1655, and the like.

Processor interface 1640 may facilitate communication betweenco-processor devices 1615 and co-processor 1675. In one implementation,processor interface 1640 may expedite encryption and decryption ofrequests or data. Input output interfaces (I/O) 1645 facilitatecommunication between user input devices 1605, peripheral devices 1610,co-processor devices 1615, and/or the like and components of thecontroller 1600 using protocols such as those for handling audio, data,video interface, wireless transceivers, or the like (e.g., Bluetooth,IEEE 1394a-b, serial, universal serial bus (USB), Digital VisualInterface (DVI), 802.11a/b/g/n/x, cellular, etc.). Network interfaces1650 may be in communication with the network 1630. Through the network1630, the controller 1600 may be accessible to remote terminal devices1620 (e.g., client devices 102). Network interfaces 850 may use variouswired and wireless connection protocols such as, direct connect,Ethernet, wireless connection such as IEEE 802.11a-x, and the like.

Examples of network 1630 include the Internet, Local Area Network (LAN),Metropolitan Area Network (MAN), a Wide Area Network (WAN), wirelessnetwork (e.g., using Wireless Application Protocol (WAP), a securedcustom connection, and the like. The network interfaces 1650 can includea firewall which can, in some embodiments, govern and/or managepermission to access/proxy data in a computer network, and track varyinglevels of trust between different machines and/or applications. Thefirewall can be any number of modules having any combination of hardwareand/or software components able to enforce a predetermined set of accessrights between a particular set of machines and applications, machinesand machines, and/or applications and applications, for example, toregulate the flow of traffic and resource sharing between these varyingentities. The firewall may additionally manage and/or have access to anaccess control list which details permissions including, for example,the access and operation rights of an object by an individual, amachine, and/or an application, and the circumstances under which thepermission rights stand. Other network security functions performed orincluded in the functions of the firewall, can be, for example, but arenot limited to, intrusion-prevention, intrusion detection,next-generation firewall, personal firewall, etc., without deviatingfrom the novel art of this disclosure.

Storage interfaces 1655 may be in communication with a number of storagedevices such as, storage devices 1690, removable disc devices, and thelike. The storage interfaces 1655 may use various connection protocolssuch as Serial Advanced Technology Attachment (SATA), IEEE 1394,Ethernet, Universal Serial Bus (USB), and the like.

User input devices 1605 and peripheral devices 1610 may be connected toI/O interface 1645 and potentially other interfaces, buses and/orcomponents. User input devices 1605 may include card readers, fingerprint readers, joysticks, keyboards, microphones, mouse, remotecontrols, retina readers, touch screens, sensors, and/or the like.Peripheral devices 1610 may include antenna, audio devices (e.g.,microphone, speakers, etc.), cameras, external processors, communicationdevices, radio frequency identifiers (RFIDs), scanners, printers,storage devices, transceivers, and/or the like. Co-processor devices1615 may be connected to the controller 1600 through interface bus 1635,and may include microcontrollers, processors, interfaces or otherdevices.

Computer executable instructions and data may be stored in memory (e.g.,registers, cache memory, random access memory, flash, etc.) which isaccessible by processors. These stored instruction codes (e.g.,programs) may engage the processor components, motherboard and/or othersystem components to perform desired operations. The controller 1600 mayemploy various forms of memory including on-chip CPU memory (e.g.,registers), RAM 1680, ROM 1685, and storage devices 1690. Storagedevices 1690 may employ any number of tangible, non-transitory storagedevices or systems such as fixed or removable magnetic disk drive, anoptical drive, solid state memory devices and other processor-readablestorage media. Computer-executable instructions stored in the memory mayhave one or more program modules such as routines, programs, objects,components, data structures, and so on that perform particular tasks orimplement particular abstract data types. For example, the memory maycontain operating system (OS) component 1692, modules and engines 1694,database tables 1696, and the like). The modules and engines 1694 caninclude, for example, a payment proxy module, a URL generation module, amapping module, and/or a payment transfer module. These modules andengines 1692 may be stored and accessed from the storage devices,including from external storage devices accessible through an interfacebus.

The database components can store programs executed by the processor toprocess the stored data. The database components may be implemented inthe form of a database that is relational, scalable and secure. Examplesof such a database include DB2, MySQL, Oracle, Sybase, and the like.Alternatively, the database may be implemented using various standarddata-structures, such as an array, hash, list, struct, structured textfile (e.g., XML), table, and/or the like. Such data-structures may bestored in memory and/or in structured files.

The controller 1600 may be implemented in distributed computingenvironments, where tasks or modules are performed by remote processingdevices, which are linked through a communications network, such as aLocal Area Network (“LAN”), Wide Area Network (“WAN”), the Internet, andthe like. In a distributed computing environment, program modules orsubroutines may be located in both local and remote memory storagedevices. Distributed computing may be employed to load balance and/oraggregate resources for processing. Alternatively, aspects of thecontroller 1600 may be distributed electronically over the Internet orover other networks (including wireless networks). Those skilled in therelevant art will recognize that portions of the system may reside on aserver computer, while corresponding portions reside on a clientcomputer. Data structures and transmission of data particular to aspectsof the controller 1600 are also encompassed within the scope of theinvention.

The above Detailed Description of embodiments of the disclosure is notintended to be exhaustive or to limit the invention to the precise formdisclosed above. While specific examples for the invention are describedabove for illustrative purposes, various equivalent modifications arepossible within the scope of the invention, as those skilled in therelevant art will recognize. For example, while processes or blocks arepresented in a given order, alternative implementations may performroutines having steps, or employ systems having blocks, in a differentorder, and some processes or blocks may be deleted, moved, added,subdivided, combined, and/or modified to provide alternativecombinations or sub-combinations. Each of these processes or blocks maybe implemented in a variety of different ways. Also, while processes orblocks are at times shown as being performed in series, these processesor blocks may instead be performed or implemented in parallel, or may beperformed at different times.

While detailed descriptions of one or more embodiments of the inventionhave been given above, various alternatives, modifications, andequivalents will be apparent to those skilled in the art without varyingfrom the spirit of the invention. For example, while the embodimentsdescribed above refer to particular features, the scope of thisinvention also includes embodiments having different combinations offeatures and embodiments that do not include all of the describedfeatures.

What is claimed is:
 1. A method comprising: receiving, by a paymentservice system, a registration request from a first user, wherein theregistration request comprises information relating to an account of thefirst user and a unique payment proxy to be associated with the firstuser; storing, by the payment service system and in a databasemaintained by the payment service system, the unique payment proxy inassociation with the account of the first user; receiving, by thepayment service system, a request to generate a web page forfacilitating payment from a second user, wherein the request comprisesthe unique payment proxy; in response to receiving the request,identifying, by the payment service system, the account of the firstuser by retrieving the information relating to the account of the firstuser from the database using the unique payment proxy included in therequest; generating, by the payment service system, an interactiveelement to be embedded within the web page, wherein the interactiveelement is generated based on the unique payment proxy, and whereininteraction with the interactive element via a sensor associated with amobile device of the second user facilitates a transfer of funds to theaccount of the first user; and upon receiving an indication that thesecond user has interacted with the interactive element of the web page,providing, by the payment service system, instructions to display a userinterface on the mobile device of the second user to complete thetransfer of funds to the account of the first user.
 2. The method ofclaim 1, further comprising: after receiving an indication that thesecond user has interacted with the interactive element of the web page,determining an identity of the second user; and determining an accountof the second user based on an association between the determinedidentity and the account of the second user stored in the databasemaintained by the payment service system.
 3. The method of claim 1,further comprising: after providing the instructions to display the userinterface to complete the transfer of funds to the account of the firstuser on the mobile device of the second user, receiving, by the paymentservice system, a payment amount from the mobile device; and based onthe received payment amount and the identified account of the firstuser, initiating, by the payment service system, a transfer of thepayment amount to the account of the first user from the second user. 4.The method of claim 1, further comprising: after providing theinstructions to display the user interface to complete the transfer offunds to the account of the first user on the mobile device of thesecond user, generating a confirmation message that includes a secondinteractive element to confirm the transfer of funds to the account ofthe first user; transmitting the confirmation message to the mobiledevice of the second user; receiving an indication that the second userhas interacted with the second interactive element from the mobiledevice of the second user; and initiating the transfer of funds to theaccount of the first user.
 5. The method of claim 1, further comprising:after providing the instructions to display the user interface tocomplete the transfer of funds to the account of the first user on aplurality of mobile devices of a plurality of second users, receiving aplurality of payment amounts from the plurality of mobile devices,respectively; identifying a plurality of accounts of each second user ofthe plurality of second users; aggregating the plurality of paymentamounts into an aggregated payment amount; and causing the aggregatedpayment amount to be transferred to the account of the first user.
 6. Amethod comprising: receiving, by a payment service system, aregistration request from a first user, wherein the registration requestcomprises information relating to an account of the first user and aunique payment proxy to be associated with the first user; storing, bythe payment service system and in a database maintained by the paymentservice system, the unique payment proxy in association with the accountof the first user; receiving, from a mobile device of a second user, arequest to transfer funds to the first user, wherein the requestcomprises the unique payment proxy; in response to receiving therequest, identifying, by the payment service system, the account of thefirst user by retrieving the information relating to the account of thefirst user from the database using the unique payment proxy included inthe request; and providing, by the payment service system to the mobiledevice of the second user, instructions to display a user interface onthe mobile device of the second user to facilitate the transfer, whereinthe user interface is personalized for the first user.
 7. The method ofclaim 6, wherein the unique payment proxy comprises: a currencyindicator that corresponds to a particular currency of a plurality ofcurrencies, and a string of one or more characters that uniquelyidentifies the first user, wherein the characters comprise letters ornumbers, and wherein the currency indicator and the string areconcatenated such that the currency indicator appears immediately beforethe string.
 8. The method of claim 6, wherein the unique payment proxyuniquely identifies the first user among users of the payment servicesystem.
 9. The method of claim 6, further comprising: associating, bythe payment service system, a unique uniform resource locatorcorresponding to the first user to information corresponding to thefirst user for a web page of the money transfer service, wherein theunique uniform resource locator is personalized for the first user andthe unique payment proxy.
 10. The method of claim 6, wherein the paymentservice system receives the request to transfer funds to the first userfrom the second user based on the unique payment proxy being enteredinto a browsing application executing on the mobile device of the seconduser.
 11. The method of claim 6, wherein the user interface tofacilitate the transfer comprises identifying information of the firstuser and an entry field configured to receive a payment amount to betransferred to the first user.
 12. The method of claim 6, furthercomprising: determining an identity of the second user based on logincredentials associated with the mobile device of the second user; anddetermining an financial account of the second user based on anassociation between the determined identify of the of the second userand the account of the second user stored in the database maintained bythe payment service system.
 13. The method of claim 6, furthercomprising: receiving, by the payment service system, a payment amountfrom the mobile device of the second user; and based on the receivedpayment amount and the identified account of the first user, initiating,by the payment service system, a transfer of the payment amount to theaccount of the first user.
 14. The method of claim 13, whereininitiating the transfer of the payment amount to the account of thefirst user comprises: generating a confirmation message that includes aninteractive element to confirm the transfer of the payment amount to theaccount of the first user; transmitting the confirmation message to themobile device of the second user; receiving an indication that thesecond user has interacted with the interactive element from the mobiledevice of the second user; and causing the payment amount to betransferred from an account of the second user to the account of thefirst user.
 15. The method of claim 6, further comprising: receiving aunique identifier associated with to the second user; and identifying anaccount of the second user based on a stored association between theunique identifier associated with the second user and the account of thesecond user in the database of the payment service system.
 16. Themethod of claim 6, further comprising: providing instructions to displaythe user interface to facilitate the transfer to a plurality of mobiledevices of a plurality of second users; receiving a plurality of paymentamounts from the plurality of mobile devices; aggregating the pluralityof payment amounts into an aggregated payment amount; and causing theaggregated payment amount to be transferred to the account of the firstuser.
 17. The method of claim 6, wherein the user interface on themobile device of the second user comprises a web page for facilitatingpayment from the second user.
 18. The method of claim 17, comprising:generating an interactive element based on the unique payment proxy,wherein interaction with the interactive element facilitates thetransfer from the second user; and embedding the interactive elementwithin the web page prior to providing the instructions to display theuser interface to the mobile device of the second user.
 19. The methodof claim 18, wherein the interaction with the interactive element is viaa sensor associated with the mobile device of the second user.
 20. Apayment service system comprising: one or more processors; a database;and one or more computer-readable non-transitory storage media coupledto one or more of the processors and comprising instructions operablewhen executed by one or more of the processors to cause the paymentservice system perform operations comprising: receiving, by a paymentservice system, a registration request from a first user, wherein theregistration request comprises information relating to an account of thefirst user and a unique payment proxy to be associated with the firstuser; storing, by the payment service system and in a databasemaintained by the payment service system, the unique payment proxy inassociation with the account of the first user; receiving, from a mobiledevice of a second user, a request to transfer funds to the first userfrom a second user , wherein the request comprises the unique paymentproxy; in response to receiving the request, identifying, by the paymentservice system, the account of the first user by retrieving theinformation relating to the account of the first user from the databaseusing the unique payment proxy included in the request; and providing,by the payment service system to the mobile device of the second user,instructions to display a user interface on the mobile device of thesecond user to facilitate the transfer, wherein the user interface ispersonalized for the first user.